Quantcast
Channel: Moved Permanently
Viewing all 51 articles
Browse latest View live

新規tmuxセッション起動時に自動で複数のウィンドウを作成してペイン分割する

$
0
0

はじめに

tmuxの新規セッション起動時に、毎回必要なウィンドウとペインを作成するのは面倒なときがあります。
そんなときは、あらかじめ必要なウィンドウとペインを作成するファイルを用意しておき、起動時にそのファイルを読み込ませることで自動でウィンドウとペインを作成するようにしておくと便利です。
ここではその方法について記載します。
なお、ウィンドウやペインについての詳細は記載していません。

ウィンドウとペイン作成ファイルの準備とそのファイルを利用したtmux起動

環境

動作確認環境は以下です。

OSCentOS 6.5 x86_64 (kernel 2.6.32-431.3.1.el6.x86_64)
tmuxバージョンtmux 1.6 (tmux-1.6-3.el6.x86_64)
必要なファイルの準備

ウィンドウとペインを生成するための以下のような設定ファイルを準備します。
ここではウィンドウとペイン生成用の2つのファイルと新規セッション起動時に読み込ませる1つのファイルの計3つのファイルを利用します。
各ファイルは、ここでは~/tmux/config以下に設置するものとしています。

~/tmux/config/tmux.window.1

1つめの新規ウィンドウとそのペイン生成用のファイルの例です。


### 1st Window
## Create New Window
new-window -1st

## Horizontal split
splitw -d
# Vertical split
splitw -h -d
# Vertical split
splitw -h -d
## Pane Resize(Over 7 lines)
resize-pane -U 7

# Move Right Pane
select-pane -R

# Move Right Pane
select-pane -R
# Vertical split
splitw -h -d

# Move Right Pane
select-pane -R
clock

# Move Under Pane
select-pane -D
~/tmux/config/tmux.window.2

2つめの新規ウィンドウ生成とそのペイン生成用のファイルの例です。


### 2nd Window
## Create New Window
new-window -n 2nd

# Vertical split
split-window -h -d
# Move Right Pane
select-pane -R

# Horizontal split
split-window -d
# Move Under Pane
select-pane -D

# Horizontal split
splitw -d
# Move Under Pane
select-pane -D

# Display Clock
clock-mode

# Move Left Pane
select-pane -L
~/tmux/config/tmux.startup

新規セッション起動時に読み込ませるファイルの例です。
~/tmux/config/tmux.window.1~/tmux/config/tmux.window.2の2つのウィンドウ、ペイン作成用ファイルを読み込ませるように記述しています。


### Layout of Window Number 1
source-file ~/tmux/config/tmux.window.1

### Layout of Window Number 2
source-file ~/tmux/config/tmux.window.2
作成したファイルを読み込ませてtmuxを起動

tmuxの内部コマンドはセミコロンで区切ることで複数のコマンドを指定して実行することができます。なお、セミコロンはバックスラッシュ\でエスケープする必要があります。

新規セッション起動時に外部ファイルを読み込ませる場合は、以下のように指定します。


$ tmux new-session \; source-file 設定ファイルPATH

作成した設定ファイルを読み込ませるようにしてtmuxのセッションを起動します。~/tmux/config/tmux.startup内に記載した各ファイルも読み込まれて、ウィンドウとペインが自動で作成されます。


$ tmux new-session \; source-file ~/tmux/config/tmux.startup

無事、起動後に、以下のような2つのウィンドウが作成され、それぞれのウィンドウにペイン分割がされていることが確認できました。

おわりに

新規tmuxセッション起動時に、自動で複数のウィンドウを作成してペイン分割する方法について、記載しました。
ここでは記載していませんが、必要なコマンドを実行したり各サーバへssh接続するように各設定ファイル内へ記述しておくこともできます。オペレーション用のウィンドウ、ペイン作成や、実行するコマンドを tmux セッション起動時に一括して動作するように設定しておくと非常に楽で便利かと思います。 screenほど多機能ではないと言われていますが、これが出来るだけでもtmuxも十分使っていけそうです。


RubyでBundlerを使ったGem管理

$
0
0

はじめに

Rubyでプログラムを書く時には必要なGemパッケージをインストールしていくことになりますが、環境に合わせてGemパッケージやそのバージョンを使い分けたり、システム環境を汚したくないとき等があります。
そんなときはディレクトリ毎にBundlerを使ってGemパッケージを管理するといろいろ便利かと思いやってみましたのでそのメモです。

Bundlerとは

Ruby環境内で利用するGemを管理するためのソフトウェアです。
Gemfileというファイルにパッケージ名、バージョンを記述してGemパッケージを管理出来ます。 Bundler自体もGemパッケージとして提供されています。

Bundlerを使ったGem管理のやり方

Bundlerのインストール

Bundlerだけは通常通りにインストールしておく必要があります。


$ gem install bundler
Gemfileの準備

まずはプログラム実行環境用のディレクトリを作成します。
そのディレクトリ配下でbundle initを実行してGemfileを作成します。


$ mkdir ~/rbdev

$ cd ~/rbdev

$ bundle init

Gemfileを編集し、インストールしたい必要なGemパッケージとそのバージョンを記述します。


$ vim Gemfile
Gemパッケージのインストール

bundle installを実行し、Gemfileに記述されたGemパッケージをインストールします。このとき、--pathオプションを指定することでGemパッケージインストール先のディレクトリを指定できます。ここではvendor/bundlerと指定しているので、~/rbdev/vendor/bundler配下にGemパッケージがインストールされます。インストール先をこのディレクトリ環境内にすることでシステム環境を不用意に汚さずに済みます。


$ bundle install --path vendor/bundler
実行

実行したいプログラム内でGemパッケージをrequireし、実行時にbundle execを指定することで、Bundler経由でインストールしたGemパッケージを読み込んでプログラムを実行できます。


$ bundle exec ruby foo.rb

おわりに

上記の内容よりもっとスマートなやり方があるかもしれませんが、Bundlerを使うことでGemパッケージを管理しやすくなると思います。
必要な環境毎にディレクトリを分けてGemfileを作成し、bundle install実行時に--pathでGemパッケージインストール先を制御することで、Gemパッケージをディレクトリ毎に管理できるので、システム環境を汚したくない場合に便利かと思います。

参考

RedHat Enterprise Linux 7 betaのインストール

$
0
0

はじめに

昨年(2013/12/11)公開されたRedHat Enterprise Linux 7betaを今更ながら触ってみようと思い、VirtualBoxを使ってインストールしてみました。

Red Hat | Red Hat Announces Availability of Red Hat Enterprise Linux 7 Beta

RedHat Enterprise Linux 7 beta

「Red Hat Enterprise Linux」は、米Red Hat社が開発および提供しているLinuxディストリビューションで、Fedora Projectが開発しているLinuxディストリビューション「Fedora」の開発の結果を取り込んでいます。
今回のRedHat Enterprise Linux 7 betaはFedora 19がベースとされており、Linuxカーネル3.10が使われています。
また、RedHat Enterprise Linux 7からアーキテクチャが64bitのみになったようです。

インストールメディアの取得

ISOイメージは以下からダウンロードできます。

インストーラの起動

VirualBox上に作成した仮想マシンのIDEにISOイメージファイルをマウントさせ、仮想マシンを起動させます。以下のような画面が表示されます。
Anacondaのインストーラ画面がずいぶん変わっています。

分かりにくいですが、デフォルトではTest this media & install Red Hat Enterprise Linux 7.0が選択されていますので、そのまま起動するとメディアのテストが実行されます。
メディアテストは実行した方が良いですが、不要な場合はキーでInstall Red Hat Enterprise Linux 7.0を選択します。

メディアのテスト

メディアのテストを実行すると以下のような画面が表示されます。手元の環境では数分で終わりました。

言語の選択

インストール作業時に使用する言語を選択します。最初は英語Engilishが選択されていますが、日本語の方がやりやすいのでJapaneseを選択して日本語表記にします。

日本語表記にしたところで続行ボタンを押下します。

インストールの概要 画面

以下のような画面になります。Red Hat Enterprise Linux 5や6のように各設定画面が順番に表示されるのではなく、設定したい項目を選択して設定を行う形になっています。
順に設定を行っていきます。

地域設定
日付と時刻の設定

日付と時刻の設定を行います。
ここでは特にデフォルトのまま変更したい点はなかったので、このまま画面左上の完了ボタンを押下します。

キーボードの設定

キーボードの設定を行います。
日本語しか選択項目がありませんので、日本語を選択します。 キーボードレイアウトを選択したら、画面左上の完了ボタンを押下します。

言語サポートの設定

インストール完了後のRed Hat Enterprise Linux 7 beta 環境で使う言語を選択します。 ここでは日本語のみ選択します。
使用言語を選択したら、画面左上の完了ボタンを押下します。

ソフトウェアの設定
インストールソースの設定

外部リポジトリの指定等を行います。特に変更点はないので、このまま画面左上の完了ボタンを押下します。

ソフトウェアの選択の設定

インストールするソフトウェアを選択します。
Red Hat Enterprise Linux 5や6のように細かいソフトウェア選択はできなくなったようです。
ここでは最小限のインストールを選択します。
インストールするソフトウェアの選択が完了したら、画面左上の完了ボタンを押下します。

システム
インストール先の設定

インストール先の設定とパーティションの設定を行います。

インストール先デバイスにローカルの標準ディスクを選択します。

パーティションの設定を行います。
パーティション構成を行いたいを選択し、画面左下のすべてのディスクの要約とブートローダー...(F)を押下します。

手動パーティション設定画面になります。
ディスクサイズが小さいのでここでは細かい指定をせず、ここをクリックして自動的に作成します(C)を押下し、パーティションを自動で作成します。

以下のようなパーティション構成になります。
デフォルトのファイルシステムにxfsが選択されています。

パーティション構成に問題がなければ、画面左上の完了ボタンを押下します。

以下のような画面が表示されますので、問題なければ変更を適用するボタンを押下し、パーティション設定をディスクに反映させます。

ネットワークとホスト名の設定

ネットワーク環境に応じてネットワーク設定を行い、必要ならホスト名の設定を行います。
インストール後に設定を行うことにして、ここでは特に何もせず、画面左上の完了ボタンを押下します。

全ての設定が完了したら、インストールの概要画面右下のインストールの開始ボタンを押下して、インストールを開始します。

インストール

インストールが開始されると以下の画面になりますが、rootパスワードの設定とユーザの作成を行わなければインストールが完了しないので設定を行います。

rootパスワードの設定

rootパスワードの設定を行い、画面左上の完了ボタンを押下します。

ユーザの作成

OSユーザ名とパスワードの設定をし、画面左上の完了ボタンを押下します。

全ての設定が完了したらインストールが完了するので、その後システムを再起動し、その後OSが起動すれば完了です。

おわりに

Red Hat Enterprise Linux 7からXFSファイルシステムの追加やsystemdによるシステム管理(init.dスクリプトの廃止)、ネットワーク設定の変更など大幅な変更がされていますが、インストーラ自体も大幅に変わったようです。
利用していくにはいろいろと変更内容を把握しておく方が良いかも知れません。

初めてのAmazon EC2インスタンス作成

$
0
0

はじめに

いろいろあって個人でのAWSアカウントを取得しましたので、実際に初めてEC2インスタンス作成した際のことについて記載します。単なる作業ログで特に面白いことはありません。

アカウント作成

当然ながらまずはAWSアカウントを作成する必要がありますが、以下リンク先公式ドキュメントの手順通りにやれば良いです。 クレジットカードの情報が必須です。電話番号認証には驚きました。

EC2インスタンス作成

実際にインスタンスを作成する際、事前に検討する必要がある事項は以下かと思いますが、 ここではVPC等他のAWSサービスを利用しておらず、初めてEC2インスタンスを作成するものとしますので、概ねデフォルト値として各設定項目について細かくは記載しません。

  • AMIの選択(OS)
  • EC2インスタンスで使うAMI(ソフトウェア構成のテンプレート)を選択します。Amazonが準備しているものの他に、自分で作成したものを利用することもできます。後の変更ができないので、事前に検討しておく必要があります。
    Amazon Linux AMI の基本 - Amazon Elastic Compute Cloud
  • インスタンスタイプ(CPU/メモリ)
  • EC2インスタンスの用途に応じてインスタンスタイプ(CPU、メモリ、ストレージ、ネットワークなどのスペック)を検討します。後の変更も可能ですが、手間がかかるので予め必要なスペックを見積もって選択します。新しいインスタンスタイプがリリースされたり古いインスタンスタイプが使用不可になったりとよく変更が加わっているので、チェックが必要です。
    Amazon EC2 インスタンスタイプ
  • ストレージタイプ/サイズ (EBS)
  • Amazon EC2 インスタンスで使用するストレージについて検討します。要件に応じてストレージタイプや容量を決める必要があります。
    Amazon Elastic Block Storage (EBS)
  • セキュリティグループ
  • EC2インスタンスのトラフィックを制御するためのファイアウォールのような機能です。作成したセキュリティグループをEC2インスタンスに紐付けて通信制御を行います。
    セキュリティグループの使用 - Amazon Elastic Compute Cloud
    デフォルトでは外部から内部(対象インスタンス)へのアクセスはSSH(22番ポート)のみ全てのIPから許可され、内部(対象インスタンス)から外部への通信は全て許可される
  • その他の設定
    • Network
    • 割り当てる仮想ネットワークを検討します。 VPCと呼ばれる自分自身で制御できる仮想的なプライベートネットワーク環境を構築できるため、それを利用するのが一般的です。
      Amazon Virtual Private Cloud
      現状では、デフォルトのVPC(172.31.0.0/16)とサブネット(172.31.0.0/16)があり、そこに所属することになります。
    • Shutdown Behavior
    • 停止時のStop/Terminateの動作について設定します。
    • Termination Protection
    • Terminate(削除)できないようにするかどうか選択します。
    • Monitoring Cloudwatch
    • Cloudwatchを利用するかどうかを選択します。
    • Tenancy
    • EC2が稼動するHWを自分自身のものとして占有するかどうかを設定します。利用料が高くなります。

なお、画面キャプチャは2014年6月末時点のものですが、AWSの管理画面はいつの間にかUIが変わったり、新サービスのリリース等によって選択項目が変更されていることが多いので、エビデンスとしての画面キャプチャも役に立たなくなることが多いです。

Launch Instance

AWSのManagement Consoleにログインし、左上のServicesからEC2を選択します。
EC2のダッシュボード画面の中央付近になる青い「Launch Instance」ボタンを押下します。

OSの選択

作成するEC2インスタンスで利用するOSを選択します。ここではAmazon Linuxを選択します。

インスタンスタイプの選択

インスタンスのタイプを選択します。後の変更も可能ですがインスタンスの停止が必要になります。

その他のインスタンスの設定

作成するインスタンスの数、PublicIP割当の有無、ネットワーク、シャットダウン処理時の動作等を設定します。 ここではデフォルト設定のままとします。ネットワークはデフォルトVPC(172.31.0.0/16)に割り当てられます。PublicIPというグローバルIPが割り当てられるようにします。

ストレージの選択

ストレージのサイズ、タイプを選択します。選択するストレージのタイプによって料金体系も多少変わります。

タグの設定

インタンスへタグという形式の独自の情報を設定することができます。これはインスタンスの管理において利用するデータなもので、後で設定することもできるのでここでは何も入力せずに進みます。

セキュリティグループの設定

セキュリティグループ(アクセス制御)の設定を行います。最初は何も設定がないので新規に作成する必要があります。デフォルトでは全てのIPアドレスからSSH(22番ポート)へのアクセスと、全てのIP/ポートへの外部アクセスのみ可能になります。 ここではデフォルトのままにしていますが、必要に応じて設定を行います。

設定内容の確認

設定内容を確認します。問題なければ「Launch」を押下します。

ログイン用のSSH秘密鍵の生成を求められます。鍵の名前を入力してダウンロードし、「Launch Instance」ボタンを押下します。

インタンス生成開始

インスタンス作成処理が開始されます。

これでインスタンス作成は完了です。

EC2インスタンスのPublicIPを確認し、生成したSSH秘密鍵を用いてec2-userというアカウントでEC2インスタンスのPublicIPへアクセスし、OSへログインできます。

おわりに

AWSのManagement Consoleすごいですね。インスタンスは簡単に作成出来ました。ただOSへの細かいリソース割り当てやディスクパーティションと言った設定はできないようなので意識する必要があるかも知れません。

CentOS 7.0のリリースとさくらのVPSへISOイメージアップロードでのインストール

$
0
0

はじめに

Red Hat Enterprise Linux互換のオープンソースのOSであるCentOSの最新版「CentOS 7」が公開されました。

6月10日にリリースされたRHEL 7から約1カ月遅れでの公開であり、2014年1月にRedHatはCentOSプロジェクトを支援していくことを表明し、RedHat社の社員をプロジェクトのメンバーに迎え入れるなどの開発体制強化の影響かも知れません。

主な新機能は以下のようです

  • 5. Major Changes - CentOS 7.0.1406 Release Notes
    • カーネル3.10.0へのアップデート
    • Linuxコンテナのサポート
    • Open VMware Toolsと3Dグラフィックドライバの提供
    • デフォルトJDKがOpenJDK7
    • 6.5から7.0へのアップグレード (まだ未対応? - 参考: In place Upgrade CentOS 6.5 to 7.0 how to.)
    • ext4のとXFSとLVMのスナップショット
    • systemd,firewalld,GRUB2への変更
    • デフォルトファイルシステムとしてのXFS
    • iSCSIおよびFCoE
    • PTPv2のサポート
    • 40Gイーサネットカードのサポート
    • 互換性のあるハードウェア上でのUEFIセキュアブートでのインストールのサポート

さくらのVPSへインストールしてみました。

さくらのVPSへのインストール

以下にISOイメージインストール機能を使ってCentOS 7をインストールします。

CentOS 7のISOイメージの取得

ISOイメージを取得します。以下リンク先本家サイトや日本国内のFTPサイトからダウンロードします。

CentOS 7のISOイメージをさくらのVPSのFTPサーバへアップロード

以下リンク先の手順通りにISOイメージをアップロードし、ISOイメージインストールを開始します。

メディアの起動

メディアからの起動後、コンソールを表示すると以下の画面が表示されます。 Anacondaのインストーラ画面がずいぶん変わっています。

分かりにくいですが、デフォルトではTest this media & install CentOS 7.0が選択されており、そのまま起動するとメディアのテストが実行されます。 メディアテストは実行した方が良いですが、ここではスキップしてキーでInstall CentOS 7.0を選択します。

言語の選択

インストール作業時に使用する言語を選択します。

デフォルトではEngilish(英語)が選択されていますが、日本語の方がやりやすいのでキーでJapanese(日本語)を選択して日本語表記にします。

インストールの概要

以下のような画面になります。
各設定画面が順番に表示されるのではなく、設定したい項目を選択して設定を行う形になっています。順に設定を行っていきます。

地域設定
日付と時刻

日付と時刻の設定を行います。
ここでは特にデフォルトのまま変更したい点はなかったので、このまま画面左上の完了ボタンを押下します。

キーボード

キーボードの設定を行います。
日本語しか選択項目がありませんので、日本語を選択します。
キーボードレイアウトを選択したら、画面左上の完了ボタンを押下します。

言語サポート

インストール完了後のCentOS 7.0環境で使う言語を選択します。
ここでは日本語のみ選択します。
使用言語を選択したら、画面左上の完了ボタンを押下します。

ソフトウェア
インストールソース

外部リポジトリの指定等を行います。
特に変更点はないので、このまま画面左上の完了ボタンを押下します。

ソフトウェアの選択

インストールするソフトウェアを選択します。
CentOS 5や6のように細かいソフトウェア選択はできなくなったようです。
ここでは最小限のインストールを選択していますが必要に応じて選択してください。
インストールするソフトウェアの選択が完了したら、画面左上の完了ボタンボタンを押下します。

システム
インストール先

インストール先のディスクデバイスを選択します。
ローカルの標準ディスクに表示されているVirtio Block Deviceを選択します。 ここではパーティション構成として自動構成のパーティション構成を選択しています。独自にパーティションを構成したい場合はパーティション構成を行いたいを選択します。
画面左上の完了ボタンボタンを押下します。

以下のような画面が表示されたら、領域を確保するボタンを押下します。

既存パーティションを削除し、領域を確保します。
ここでは/を削除して領域を確保しています。

領域を確保するボタンを押下します。

自動でパーティションが構成されます。

ネットワークとホスト名

ネットワークとホスト名の設定を行います。 Ethernet(eth0)を選択し、画面右下の設定ボタンを押下します。

IPv4のセッティング項目を選択します。
方式手動を選択し、契約しているさくらのVPSのIPアドレスネットマスクゲートウェイDNSサーバを入力します。
入力が完了したら右下の保存ボタンを押下します。

契約しているさくらのVPSのホスト名を画面左下のホスト名に入力し、画面左上の完了ボタンボタンを押下します。

インストールの開始

以下のように各項目で!アイコンが表示されなくなったら、画面右下のインストールの開始ボタンを押下します。

インストールが開始されます。
rootパスワードの設定とユーザ作成を完了しないとインストールが完了しませんので設定を行います。

rootパスワード

パスワードを入力します。
入力が完了したら画面左上の完了ボタンを押下します。

ユーザの作成

ユーザを作成します。
各種入力が完了したら画面左上の完了ボタンを押下します。

再起動

全ての設定が完了し、インストールが完了したら画面右下の再起動ボタンを押下します。

完了

再起動後、以下のようにログインプロンプトが表示されれば完了です。

おわりに

以上でさくらのVPSへのCentOS 7.0のインストールが完了です。
この状態ではrootログイン可能だったりパスワード認証可能だったりなので、まずは最低限sshの設定はした方が良いかと思います。
systemdの導入でサービスの管理が従来と大きく変わっていたりと使っていくにはもう少し勉強が必要そうです。

CentOS 7でネットワークの状態確認するためのipコマンド、ssコマンドについてメモ

$
0
0

はじめに

CentOS 7ではnet-toolsパッケージ(ifconfigコマンド、netstatコマンド等)が非推奨になりデフォルトではインストールされておらず、iprouteパッケージ(ipコマンド、ssコマンド)が使われることになっています。

慣れていないコマンドはなかなかオプション等を覚えられず、最初は苦労しましたので、すでにいろいろなブログ記事等で紹介されていますが、自分用に簡単な使い方をいくつかメモしておきます。

ipコマンド, ssコマンドによるネットワーク確認

基本的な使い方はhelpで確認できます。必要に応じてmanで確認します。

  • ipコマンドの使い方

Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] -batch filename
where OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable |
tunnel | tuntap | maddr | mroute | mrule | monitor | xfrm |
netns | l2tp | tcp_metrics | token }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-f[amily] { inet | inet6 | ipx | dnet | bridge | link } |
-4 | -6 | -I | -D | -B | -0 |
-l[oops] { maximum-addr-flush-attempts } |
-o[neline] | -t[imestamp] | -b[atch] [filename] |
-rc[vbuf] [size]}
  • ssコマンドの使い方

Usage: ss [ OPTIONS ]
ss [ OPTIONS ] [ FILTER ]
-h, --help this message
-V, --version output version information
-n, --numeric don't resolve service names
-r, --resolve resolve host names
-a, --all display all sockets
-l, --listening display listening sockets
-o, --options show timer information
-e, --extended show detailed socket information
-m, --memory show socket memory usage
-p, --processes show process using socket
-i, --info show internal TCP information
-s, --summary show socket usage summary
-b, --bpf show bpf filter socket information

-4, --ipv4 display only IP version 4 sockets
-6, --ipv6 display only IP version 6 sockets
-0, --packet display PACKET sockets
-t, --tcp display only TCP sockets
-u, --udp display only UDP sockets
-d, --dccp display only DCCP sockets
-w, --raw display only RAW sockets
-x, --unix display only Unix domain sockets
-f, --family=FAMILY display sockets of type FAMILY

-A, --query=QUERY, --socket=QUERY
QUERY := {all|inet|tcp|udp|raw|unix|packet|netlink}[,QUERY]

-D, --diag=FILE Dump raw information about TCP sockets to FILE
-F, --filter=FILE read filter information from FILE
FILTER := [ state TCP-STATE ] [ EXPRESSION ]
ネットワークデバイスの状態確認

ipコマンドのaddressオブジェクトを用いてネットワークデバイスのIPアドレスや状態を確認できます。

構文

  • すべてのデバイスのIPアドレスと状態を確認

ip address show

 ※addressaと短縮可能、showは省略可能

  • 特定のデバイスのIPアドレスと状態を確認

ip address show dev デバイス名

 ※addressaと短縮可能

実行例

以下が実行例です。

  • すべてのデバイスのIPアドレスと状態を確認

% ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
inet brd <ブロードキャストアドレス> scope global eth0
valid_lft forever preferred_lft forever
inet6 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
4: eth2: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
  • eth0デバイスのIPアドレスと状態を確認

% ip a show dev eth0
2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 52:54:11:00:42:42 brd ff:ff:ff:ff:ff:ff
inet brd <ブロードキャストアドレス> scope global eth0
valid_lft forever preferred_lft forever
inet6 scope link
valid_lft forever preferred_lft forever
ネットワークデバイスのリンクのダウン/アップ、状態確認

ipコマンドのlinkオブジェクトを用いてネットワークデバイスのリンク状態を確認できます。

構文
  • ネットワークデバイスをリンクダウン

ip link set デバイス名 down

 ※linklと短縮可能

  • ネットワークデバイスをリンクアップ

ip link set デバイス名 up

 ※linklと短縮可能

  • 全てのネットワークデバイスのリンク確認

ip link show

 ※linklと短縮可能、showは省略可能

  • 特定のネットワークデバイスのリンク確認

ip link show dev デバイス名

 ※linklと短縮可能

実行例

以下が実行例です。

  • ネットワークデバイスのリンクダウン

# ip l set eth1 down

  • ネットワークデバイスのリンク状態確認

# ip l show eth1
3: eth1: mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff

  • ネットワークデバイスのリンクアップ

# ip link set eth1 up

  • ネットワークデバイスのリンク状態確認

# ip link show dev eth1
3: eth1: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
パケットの処理情報確認

ipコマンドの-sオプションでデバイスのより詳細な情報を表示できます。linkオブジェクトと組み合わせることで、パケットの処理状態を表示できます。

構文
  • 全てのネットワークデバイスのパケットの処理情報を表示

ip -s link show

 ※linklと短縮可能、showは省略可能

  • 全てのネットワークデバイスのパケットの処理情報を表示

ip -s link show dev デバイス名

 ※linklと短縮可能

実行例

# ip -s l
1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
2060 19 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2060 19 0 0 0 0
2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
53242888 780447 0 0 0 0
TX: bytes packets errors dropped carrier collsns
4936364 25919 0 0 0 0
3: eth1: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
468 6 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
4: eth2: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
468 6 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0

# ip -s l show dev eth0
2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
53909617 790762 0 0 0 0
TX: bytes packets errors dropped carrier collsns
5012886 26334 0 0 0 0
ルーティングテーブル確認

ipコマンドのrouteオブジェクトを用いてルーティングテーブルのエントリを確認できます。

構文

ip route show

 ※routerと短縮可能、showは省略可能

実行例

# ip r
default via <デフォルトゲートウェイアドレス> dev eth0 proto static metric 1024
<サブネットIPアドレス> dev eth0 proto kernel scope link src
arpキャッシュ確認

ipコマンドのneighbourオブジェクトを用いてARPやNDISCのキャッシュ状態を確認できます。

構文

ip neighbour show

 ※neighbournと短縮可能、showは省略可能

実行例

# ip n
dev eth0 lladdr STALE
dev eth0 lladdr DELAY
TCP通信状態確認
構文

ssコマンドの-aオプションを指定すると全ての通信ソケットが表示され、-tオプションを指定するとtcp通信のコネクション状況を確認できます。-nオプションを指定すると、通信しているサービスの名前ではなくポート番号が表示されます。


ss -a -t (-n)
実行例

# ss -ant
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 128 *:22 *:*
ESTAB 0 52 xxx.xxx.xxx.xxx:22 xxx.xxx.xxx.xxx:59702
ESTAB 0 76 xxx.xxx.xxx.xxx:22 xxx.xxx.xxx.xxx:55329
TIME-WAIT 0 0 xxx.xxx.xxx.xxx:22 xxx.xxx.xxx.xxx:59080
LISTEN 0 100 ::1:25 :::*
LISTEN 0 128 :::22 :::*
UDP通信状態確認
構文

ssコマンドの-aオプションを指定すると全ての通信ソケットが表示され、-uオプションを指定するとudp通信のコネクション状況を確認できます。-nオプションを指定すると、通信しているサービスの名前ではなくポート番号が表示されます。


ss -a -u (-n)
実行例

# ss -a -n -u
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *:123 *:*
UNCONN 0 0 *:5353 *:*
UNCONN 0 0 *:51496 *:*
UNCONN 0 0 127.0.0.1:323 *:*
UNCONN 0 0 :::123 :::*
UNCONN 0 0 ::1:323 :::*

おわりに

よく使いそうなものをメモがてら書き連ねました。ただ、ネットワークはデフォルトでNetworkManagerで管理されるようになっているのでそのやり方も確認しておく必要がありそうです。

CentOS 7でPostgreSQL 9.2のRPMパッケージをインストールしてsystemdを使って起動する

$
0
0

はじめに

CentOS 7.0へPostgreSQLのRPMパッケージをインストールし、systemd経由で起動させるための備忘録です。2014/8/31時点でCent0S 7.0のBaseリポジトリに登録されているPostgreSQLのバージョンは9.2.7-1でした。

PostgreSQLのインストールと起動

環境

インストール環境は以下です

プラットフォームさくらのVPS (SSD 1G)
OSCentOS 7.0 x86_64 (64bit)
PostgreSQLのRPMパッケージのインストール

PostgreSQLのRPMパッケージをインストールします。Baseリポジトリにパッケージが存在するので、yumでインストールします。


% sudo yum install postgresql postgresql-server postgresql-libs postgresql-devel postgresql-contrib
PostgreSQLの起動

起動を試みますが失敗します。


% sudo systemctl start postgresql.service
[sudo] password for shimizu:
Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details.

詳細を観るためにstatusを確認しろ、といったメッセージが出ますのでとりあえず確認してみます。PostgreSQLのデータディレクトリがない、といった内容のメッセージが出力されているようです。


% sudo systemctl status postgresql.service
postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled)
Active: failed (Result: exit-code) since 日 2014-08-31 21:36:51 JST; 16s ago
Process: 6571 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=1/FAILURE)

PostgreSQLのユニットファイル/usr/lib/systemd/system/postgresql.serviceでデータディレクトリに何が指定されているかを確認してみると/var/lib/pgsql/dataが指定されていることがわかります。
データディレクトリの場所を変更したければ、この項目を修正します。ここでは変更せずに進めます。


% cat /usr/lib/systemd/system/postgresql.service
・・・
# Location of database directory
Environment=PGDATA=/var/lib/pgsql/data
・・・

指定されているデータディレクトリを作成します。


% sudo mkdir -p /var/lib/pgsql/data

所有者、所有グループをpostgresへ変更します。


% sudo chown postgres:postgres /var/lib/pgsql/data

postgresユーザへスイッチします。


% sudo -i -u postgres

postgresユーザでデータベースクラスタを初期化します。


-bash-4.2$ initdb -D '/var/lib/pgsql/data'
データベースシステム内のファイルの所有者は"postgres"ユーザでした。
このユーザがサーバプロセスを所有しなければなりません。

データベースクラスタはロケール"ja_JP.UTF-8"で初期化されます。
したがってデフォルトのデータベース符号化方式はUTF8に設定されました。
initdb: ロケール"ja_JP.UTF-8"用の適切なテキスト検索設定が見つかりません
デフォルトのテキスト検索設定はsimpleに設定されました。

ディレクトリ/var/lib/pgsql/dataの権限を設定しています ... ok
サブディレクトリを作成しています ... ok
デフォルトのmax_connectionsを選択しています ... 100
デフォルトの shared_buffers を選択しています ... 32MB
設定ファイルを作成しています ... ok
/var/lib/pgsql/data/base/1にtemplate1データベースを作成しています ... ok
pg_authidを初期化しています ... ok
依存関係を初期化しています ... ok
システムビューを作成しています ... ok
システムオブジェクトの定義をロードしています ... ok
照合順序を作成しています ... ok
変換を作成しています ... ok
ディレクトリを作成しています ... ok
組み込みオブジェクトに権限を設定しています ... ok
情報スキーマを作成しています ... ok
PL/pgSQL サーバサイド言語をロードしています ... ok
template1データベースをバキュームしています ... ok
template1からtemplate0へコピーしています ... ok
template1からpostgresへコピーしています ... ok

警告: ローカル接続向けに"trust"認証が有効です。
pg_hba.confを編集する、もしくは、次回initdbを実行する時に-Aオプショ
ン、または、--auth-localおよび--auth-hostを使用することで変更するこ
とができます。

成功しました。以下を使用してデータベースサーバを起動することができます。

postmaster -D /var/lib/pgsql/data
または
pg_ctl -D /var/lib/pgsql/data -l logfile start

これで準備が整いました。postgresユーザからログアウトします。


-bash-4.2$ exit

改めて起動を試みます。


% sudo systemctl start postgresql.service

状態を確認してみます。


% sudo systemctl status postgresql.service
postgresql.service - PostgreSQL database server
Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled)
Active: active (running) since 日 2014-08-31 22:07:22 JST; 20s ago
Process: 7027 ExecStart=/usr/bin/pg_ctl start -D ${PGDATA} -s -o -p ${PGPORT} -w -t 300 (code=exited, status=0/SUCCESS)
Process: 7021 ExecStartPre=/usr/bin/postgresql-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS)
Main PID: 7031 (postgres)
CGroup: /system.slice/postgresql.service
├─7031 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
├─7032 postgres: logger process
├─7034 postgres: checkpointer process
├─7035 postgres: writer process
├─7036 postgres: wal writer process
├─7037 postgres: autovacuum launcher process
└─7038 postgres: stats collector process

8月 31 22:07:22 www4242gi.sakura.ne.jp systemd[1]: Started PostgreSQL database server.

プロセスを確認してみます。


% ps auxfwww | grep postgres
shimizu 7140 0.0 0.0 112656 988 pts/0 S+ 22:47 0:00 \_ grep --color=auto postgres
postgres 7031 0.0 0.5 233264 9464 ? S 22:07 0:00 /usr/bin/postgres -D /var/lib/pgsql/data -p 5432
postgres 7032 0.0 0.0 193012 1460 ? Ss 22:07 0:00 \_ postgres: logger process
postgres 7034 0.0 0.0 233264 1668 ? Ss 22:07 0:00 \_ postgres: checkpointer process
postgres 7035 0.0 0.1 233264 1940 ? Ss 22:07 0:00 \_ postgres: writer process
postgres 7036 0.0 0.0 233264 1444 ? Ss 22:07 0:00 \_ postgres: wal writer process
postgres 7037 0.0 0.1 234088 2932 ? Ss 22:07 0:00 \_ postgres: autovacuum launcher process
postgres 7038 0.0 0.0 193008 1672 ? Ss 22:07 0:00 \_ postgres: stats collector process

問題ないようです。

PostgreSQLのデータベースへの接続

データベースにログインしてみます。
※デフォルトのpg_hba.confの設定ではlocalからの接続がtrust(PostgreSQLデータベースサーバに接続できる全てのユーザが、任意のPostgreSQLユーザとしてパスワードなしでログインすることを許可する)設定になっていますので、どのOSユーザからでもログインできるはずです。


% psql -U postgres
psql (9.2.7)
"help"でヘルプを表示します.

postgres=#

問題ないようです。
接続を終了するには、\qを入力します。

おわりに

CentOS 7.0へPostgreSQL 9.2のRPMパッケージをインストールしてからPostgreSQLを起動して接続するまでの基本的な手順を記載しました。systemdはまだよく分かりません。

参考

Linuxで文字化けしたり記号で始まるファイルやディレクトリをシェルから削除する

$
0
0

はじめに

Linux系のOSで誤って~-?などのような記号で始まるファイルが出来てしまった場合に、bash等のシェルから削除する方法を調べてみました。

削除方法

inodeの番号を利用した削除方法

やり方としては、削除対象ファイルのinode番号を調べ、そのファイルをfindコマンドでinode番号(ファイルの作成日時、パーミッション、サイズ等々のメタ情報の管理番号)で抽出してxargs、またはexecに渡してrmで削除するというものになります。
ここでは、以下の~というファイルを削除します。


% ls | head
~
Applications
Desktop
Documents
Downloads
Dropbox
Fiddler2
Library
Movies
Music

lsコマンドの-iオプションでファイルのinode番号を表示できます。


-i, --inode
各ファイルの i ノード番号を表示する
(man ls参照)

これで文字化けしたファイルのinode番号を調べます。左の数値がinode番号になります。


% ls -i | head
31290093 ~
30980372 Applications
379474 Desktop
379270 Documents
379367 Downloads
390474 Dropbox
11789816 Fiddler2
379464 Library
379514 Movies
379516 Music

findコマンドの-inumオプションとinode番号を指定することで該当ファイルを抽出できます。


% find . -inum 31290093
./~

inode番号で抽出する対象に間違いがないことが確認できたらxargs rmの引数に渡して削除を実行します。


% find . -inum 32735580 | xargs rm
その他ある特定の文字で始まるファイルの削除方法
-で始まるファイルの削除方法

-で始まるファイルはrm--オプションを付与して、その後に-で始まるファイルを指定することで削除できます。


NOTE
The rm command uses getopt(3) to parse its arguments, which allows it to accept the `--' option which will cause it to stop processing flag options at that point.
This will allow the removal of file names that begin with a dash (`-'). For example:
rm -- -filename
The same behavior can be obtained by using an absolute or relative path reference. For example:
rm /home/user/-filename
rm ./-filename
(man rm参照)

以下の-で始まるファイルを削除します。


% ls | head
-
Applications
Desktop
Documents
Downloads
Dropbox
Fiddler2
Library
Movies
Music

マニュアル通りrmコマンドの--の後に-で始まるファイルを削除します。


% rm -rf -- -

おわりに

以上、単なるメモでした。コマンドオプションの使いかたをもっときちんと覚えるだけでやれること増えるなーと思いました。

参考


CentOS 7.0ヘAmazon EC2 API Toolsの実行環境を準備する

$
0
0

はじめに

最近AWSを使っているので、CentOSにAmazon EC2 API Toolsの実行環境を準備した際のメモです。

Amazon EC2 API Toolsとは

Amazon EC2 API Toolsは、Amazon EC2サービスに対するクライアント側のインターフェースとして機能し、EC2インスタンスの作成や起動、セキュリティグループの操作などを実行するために利用します。

Amazon EC2 API Toolsの導入

事前準備

事前にAWS API アクセスキー/シークレットキーを取得しておきます。またJavaが必要なので、事前にインストールしておく必要があります。本環境では2014/11/30時点最新版JDKのバージョン1.8.0_25をOracle社のサイトから取得しています。

環境

導入環境は以下です。

プラットフォームさくらのVPS (SSD 1G)
OSCentOS 7.0
JavaバージョンJDK 1.8.0_25
Java設置先ディレクトリ($JAVA_HOME)td>~/local/jdk1.8.0_25
Amazon EC2 API Toolsバージョン1.7.2.3
Amazon EC2 API Tools設置先ディレクトリ($EC2_HOME)~/local/ec2-api-tools-1.7.2.3
Amazon EC2 API Toolsの取得と展開

Amazon EC2 API ToolsはZIPファイルとしてAmazon S3に設置されているようですので、ファイルをダウンロードして適当な場所に展開します。


% wget -P ~/local http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
--2014-12-06 21:02:39-- http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
s3.amazonaws.com (s3.amazonaws.com) をDNSに問いあわせています... 54.231.244.4
s3.amazonaws.com (s3.amazonaws.com)|54.231.244.4|:80 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 16518332 (16M) [binary/octet-stream]
`/tmp/ec2-api-tools.zip'に保存中

100%[=======================================================>] 16,518,332 4.49MB/s 時間 4.2s

2014-12-06 21:02:43 (3.72 MB/s) - `/home/hogehoge/local/ec2-api-tools.zip'へ保存完了 [16518332/16518332]

% unzip ~/local/ec2-api-tools.zip -d ~/local
Archive: /home/hogehoge/local/ec2-api-tools.zip
creating: /home/hogehoge/ec2-api-tools-1.7.2.3/
inflating: /home/hogehoge/ec2-api-tools-1.7.2.3/THIRDPARTYLICENSE.TXT
creating: /home/hogehoge/ec2-api-tools-1.7.2.3/bin/
・・・
環境変数の設定

必要な環境変数を設定します。

Java(JDK)の環境変数設定

JDK設置先(JAVA_HOME)を環境変数として設定します。


% export JAVA_HOME=~/local/jdk1.8.0_25
EC2 API Toolsの環境変数設定

Amazon EC2 API Tools設置先を環境変数として設定します。


% export EC2_HOME=~/local/ec2-api-tools-1.7.2.3

Amazon EC2 API Toolsのコマンド群へのPATHを環境変数として設定します。


% export PATH=$PATH:$EC2_HOME/bin
AWSのアクセスキー/シークレットキーの環境変数設定

AWSのアクセスキー/シークレットキーの値を環境変数として設定します。


% export AWS_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxx
% export AWS_SECRET_KEY=xxxxxxxxxxxxxxxxxxxxx
AWSのリージョンの環境変数設定

AWSのリージョンを環境変数として設定します。


% export EC2_URL=https://ec2.ap-northeast-1.amazonaws.com
Amazon EC2の公開鍵/秘密鍵の環境変数設定

Amazon EC2の公開鍵/秘密鍵設置先を環境変数として設定します。EC 2インスタンスへのオペレーションを行わない場合はこの設定は不要です。


% export EC2_PRIVATE_KEY=~/.ssh/my-key.pem
% export EC2_CERT=~/.ssh/my-crt.pem
Amazon EC2 API Toolsの実行テスト

Amazon EC2 API Toolsに含まれているコマンドの一つで動作のテストを行います。ここでは作成したインスタンスの一覧を取得するためのec2-describe-instancesを実行してみます。
無事インスタンスの一覧を取得できれば完了です。


% ~/local/ec2-api-tools-1.7.2.3/bin/ec2-describe-instances
<略>

おわりに

Amazon EC2 API Toolsの実行環境が準備できました。

参考

Amazon EC2 API Toolsを使ってVMDKファイルをAWS環境へインポートする

$
0
0

はじめに

VMDKファイルをAmazon EC2にインポートして起動する方法のメモです。

Amazon EC2 API Toolsを利用したVMDKファイルのインポート

環境

環境は以下です。CentOS 7からAmazon EC2 API Toolsを使ってAWS環境へVMDKファイルをインポートします。
Amazon EC2 API Toolsを実行するためにJavaの実行環境が必要になりますので、別途インストールする必要があります。また、APIキー、アクセスキーを準備します。
VMDKファイルのインポート先にS3を利用する必要があるため、S3バケットを作成しておく必要があります。

プラットフォームさくらのVPS (SSD 1G)
OSCentOS 7.0
JavaバージョンJDK 1.8.0_25
Java設置先ディレクトリ($JAVA_HOME)td>~/local/jdk1.8.0_25
Amazon EC2 API Toolsバージョン1.7.2.3
Amazon EC2 API Tools設置先ディレクトリ($EC2_HOME)~/local/ec2-api-tools-1.7.2.3
インポート用VM設置先S3バケット※S3バケットを準備
VMDKファイル※boxファイルから取り出したVMDKファイル
インポート実行

必要な環境変数を設定します。

Java(JDK)の環境変数設定

JDK設置先(JAVA_HOME)を環境変数として設定します。


% export JAVA_HOME=~/local/jdk1.8.0_25
EC2 API Toolsの環境変数設定

Amazon EC2 API Tools設置先を環境変数として設定します。


$ export EC2_HOME=~/local/ec2-api-tools-1.7.2.3
AWSのアクセスキー/シークレットキーの環境変数設定

AWSのアクセスキー/シークレットキーの値を環境変数として設定します。


$ export AWS_ACCESS_KEY=xxxxxxxxxxxx
$ export AWS_SECRET_KEY=xxxxxxxxxxxx
インポート実行

ec2-import-instanceでインポートを実行します。hogehoge.vmdk の部分にはインポートしたいVMDKファイルをフルパスで指定します。


$ ec2-import-instance hogehoge.vmdk -t t2.micro -f VMDK -a x86_64 --bucket s3-hogehoge -o $AWS_ACCESS_KEY -w $AWS_SECRET_KEY
  • 書式

-t, --instance-type: 起動インスタンスタイプ
-f, --format: インポート対象ファイルの形式
-a, --architecture: VMイメージのアーキテクチャを指定(デォルトは i386)
-p, --platform: 仮想マシンのプラットフォームを指定
-b, --bucket: インポート先S3バケット名を指定
-o, --owner-akid: アクセスキーIDを指定
-w, --owner-sak: シークレットキーを指定

アップロードが完了するとS3バケットにファイルが作成され、US West(Origon)にインスタンスが作成されています。

おわりに

以上がVMDKファイルをインポートする手順となります。S3バケットのファイルは不要なので削除しておきましょう。

YosemiteへアップデートするとHomebrewが動かなくなる

$
0
0

はじめに

MACのOSをyosemiteにアップデートした後、Homebrewが動かなくなりました

原因と対応手段

事象

yosemiteにアップデート後にbrewコマンドを実行すると、以下のエラーが出るようになりました。


$ brew
/usr/local/bin/brew: /usr/local/Library/brew.rb: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby: bad interpreter: No such file or directory
/usr/local/bin/brew: line 21: /usr/local/Library/brew.rb: Undefined error: 0
原因

yosemiteへのアップデート後にRubyのバージョンが1.8から2.0に変わりPATHも変更されましたが、Homebrewのプログラムに記載されているRubyのパスが1.8のままのため、エラーとなってます。

解決策

最新のHomebrewでは既にこの修正が取り込まれているようなので、Homebrewのプログラムを最新にすることで解決できます。 brew repository(デフォルト /usr/local)に移動して、その後gitコマンドでローカルリポジトリの更新を実行します。


$ cd /usr/local
$ git pull origin master

これでbrewコマンドを実行できます。


% brew
Example usage:
brew [info | home | options ] [FORMULA...]
brew install FORMULA...
brew uninstall FORMULA...
brew search [foo]
brew list [FORMULA...]
brew update
brew upgrade [FORMULA...]
brew pin/unpin [FORMULA...]

Troubleshooting:
brew doctor
brew install -vd FORMULA
brew [--env | config]

Brewing:
brew create [URL [--no-fetch]]
brew edit [FORMULA...]
open https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Formula-Cookbook.md

Further help:
man brew
brew home

おわりに

これでHomebrewが動くようになりました。定期的なアップデートは重要ですね。

参考

FreeBSD 10.0-RELEASEをFreeBSD 10.1-RELEASEへアップグレード

$
0
0

はじめに

2014/11/14 FreeBSD 10-RELEASEが公開されました。

さくらのVPSで使っているFreeBSD 10.0-RELEASEを10.1-RELEASEへアップグレードしてみましたので、その際に実施した手順を記載します。

FreeBSD 10.0-RELEASEを10.1-RELEASEへアップグレード

公式マニュアルの手順を元に、アップデートを実施します。

実行環境

実行環境は以下となります。

プラットフォームさくらのVPS 512
OSFreeBSD 10.0-RELEASE-p0 (amd64)
FreeBSDのアップグレード

アップグレードを実施します。まず、rootにスイッチします。


> su -
アップグレード

freebsd-updateコマンドを使ってFreeBSD10.0-RELEASEをFreeBSD 10.1-RELEASEへアップグレードします。


# freebsd-update -r 10.1-RELEASE upgrade

更新対象となるファイルに対して、Does this look reasonable (y/n)?(変更に問題ないか?)といったことを何度か聞かれるので、一応確認して問題なければy(yes)と入力します。


Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 10.0-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base

The following components of FreeBSD do not seem to be installed:
world/doc world/games world/lib32

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.1-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
・・・
・・・
・・・
/usr/src/usr.sbin/zzz/Makefile
/usr/src/usr.sbin/zzz/zzz.8
/usr/src/usr.sbin/zzz/zzz.sh
/var/db/mergemaster.mtree
/var/yp/Makefile.dist
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".
カーネル/カーネルモジュール更新

更新ファイルはまだ反映されていないので、上記freebsd-updateコマンド実行後の最後のメッセージにある通りに、freebsd-update installコマンドを実行します。


# freebsd-update install

更新が反映(ディスクへ書き込み)されます。


Installing updates...
Kernel updates have been installed. Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

上記メッセージに表示されているとおり、OS再起動を実施し、新しいカーネル(10.0-RELEASE)で起動させます。


# shutdown -r now

起動後、OSバージョンが10.0-RELEASEとなっていることを確認します。


> uname -r
10.1-RELEASE
古いライブラリ/ファイル類の削除

rootへスイッチします。


> su -

再びfreebsd-updateコマンドを実行します。


# /usr/sbin/freebsd-update install

古い共有ライブラリとオブジェクトファイルを削除されます。


Installing updates...
Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates
ZFSファイルシステムとストレージプールの更新

ファイルシステムにZFSを使用している場合、現在動作しているZFSファイルシステムとストレージプールに対して以下のコマンドを実行してアップグレードを実行します。


# zpool upgrade -a

This system supports ZFS pool feature flags.

Enabled the following features on 'rpool':
spacemap_histogram
enabled_txg
hole_birth
extensible_dataset
embedded_data
bookmarks
filesystem_limits

If you boot from pool 'rpool', don't forget to update boot code.
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

メッセージの最後に表示されている通り、ディスクにbootコードを書き見ます。


# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
bootcode written to ada0
パッケージのアップデート

最新のバイナリパッケージへアップデートします。


# pkg upgrade -f

おわりに

以上で、FreeBSD 10.0-RELEASEから10.1-RELEASEへの更新が完了しました。

WordPressのRevSliderプラグインを狙ったマルウェアSoakSoak

$
0
0

はじめに

昨年末より、WordPressのスライダープラグイン "RevSlider"に対して、SoakSoakというマルウェアでの攻撃が確認されているようです。

攻撃方法

攻撃者はまず、"revicons.eot"や "wp-config.php"のファイルが存在するか、アクセス可能であるかを確認するために、以下のようなリクエストを送信します。


GET /wp-content/plugins/revslider/rs-plugin/font/revicons.eot HTTP/1.1″ 200

GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.0″ 202

ファイルの存在が確認できた場合、攻撃者は対象サイトに脆弱性のある Revslider が利用されていると判断し、Revslider の脆弱性を利用してファイルをアップロードしようとします。


“POST /wp-admin/admin-ajax.php HTTP/1.1″ 200

この攻撃が成功した場合、/wp-content/plugins/revslider/temp/update_extract/revslider/update.phpへアクセスする為に、 Filesman と呼ばれるバックドア(一度侵入に成功した攻撃者が、後から何度も侵入するために仕掛けておく秘密の入り口)が仕込まれます。


“GET /wp-content/plugins/revslider/temp/update_extract/revslider/update.php HTTP/1.1″ 200

そこから、攻撃者はswfobject.jsファイルを変更して2つ目のバックドアを仕込み、サイト訪問者をsoaksoak.ruへリダイレクトするマルウェアを注入します。

対策

対策としてはやはり基本的なことですが、以下のような手法が考えられます。

  • WordPress のバージョンアップ
  • プラグインのバージョンアップ
  • /wp-admin 配下のアクセス制限

参考

JAWS DAYS 2015の資料

$
0
0

はじめに

JAWS DAYS 2015の資料をまとめてみました。

セッション資料

[キーノート]クラウドとコミュニティのこれまでとこれから - 小島 英揮 様 [アマゾン データ サービス ジャパン(株)]
スマートニュースの世界進出を支えるログ解析基盤 on AWS - 坂本 卓巳 様 [スマートニュース株式会社]
エイチ・アイ・エスでのAWS活用事例 - 榎本 貴之 様 [株式会社エイチ・アイ・エス]
コンソールゲームをAWSで世界展開してみた - 中丸 良 様 [株式会社SUPINF]
[Deep Dive] AWS OpsWorksの仕組みと活用方法のご紹介 - 舟﨑 健治 様 [アマゾン データ サービス ジャパン(株)]
“DevOps”がないスタートアップの“DevXXX”の話 - 藤井 拓也 様 [トークノート株式会社]
REST Webアプリ開発 - 鈴木 史郎 様 [株式会社鈴木商店]
Data Engineering at VOYAGE GROUP - 鈴木 健太 様 [株式会社VOYAGE GROUP]
[Aceに聞け] Cognito + SNS + zabbixでサーバー監視業務アプリを作ってみた - 芦野 光 様 [東北電子専門学校 高度ITエンジニア科]
[Deep Dive]モバイル開発を支えるAWS Mobile Services - 西谷 圭介 様 [アマゾン データ サービス ジャパン(株)]
DevOps が普及した今だからこそ考えるDevOpsの次の姿 - 安達 輝雄 様 [株式会社ソニックガーデン]
Hadoop Trends and Best Practices of Running Hadoop on EC2 - 蒋 逸峰 様 [Hortonworks]
Movable Type for AWS で始めるお手軽サイト構築 - 高山 裕司 様 [シックス・アパート株式会社]
「納品のない受託開発」の先にある「エンジニアの働きかたの未来」 - 倉貫 義人 様 [株式会社ソニックガーデン]
[Deep Dive]WorksSpacesと周辺サービス - 佐竹 陽一 様 [株式会社サーバーワークス]
北海道 x 農業 x クラウド - 小林 晋也 [株式会社ファームノート] / 田名辺 健人 様 [株式会社ファームノート]
開発するように運用するインフラ - 土居 正行 様 [Kaizen Platform, Inc.]
モバイルファースト時代のクラウドネイティブアーキテクチャ - 大橋 力丈 様 [クラスメソッド株式会社]
[初心者ハンズオン(RDS)]簡単!お手軽!!RDSでDR環境構築 - 山﨑 奈緒美 様 [株式会社エイチ・アイ・エス]
ドコモの画像認識APIもAWSだった - 赤塚 隼 [株式会社NTTドコモ] / 山口 陽平 様 [有限会社来栖川電算]
東急ハンズのクラウドデザインパターン - 長谷川 秀樹 様 [株式会社東急ハンズ / ハンズラボ株式会社]
[Deep Dive]AWS Lambdaを紐解く - 西谷 圭介 様 [アマゾン データ サービス ジャパン(株)]
網元起動隊入隊式 - 新沼貴行 様 [株式会社モンスター・ラボ] / 立花拓也 [株式会社ヘプタゴン] / 武田一成 [株式会社ナカノアイシステム]
ド・エンタープライズな情シスとクラウドと私 - 多田 歩美 様 [本田技研工業株式会社]
[Deep Dive] Infra寄りのDevがお送りする「RDS for Aurora」徹底検証 - 照井 将士 様 [ジグソー株式会社]
新サービスをSimpleWorkflow + OpsWorksで構築して解ったこと(仮) - 千葉 哲也 様 [株式会社サーバーワークス]
IoT時代のデータ伝送とインフラに求められている機能 - 松下 享平 様 [ぷらっとホーム株式会社]

LT資料

[JAWS Days 2015 LT]使い始めて3年半、ようやくテスト始めました
AWSを使って沖縄から世界へ (JAWS DAYS 2015 A-1 GP LT大会)
AWS ロボ in JAWSDAYS

僕が使ってるbashの設定(.bashrcと.inputrc)

$
0
0

はじめに

Linux系OSのシステムを運用する上ではシェルの機能は重要です。zshなどはかなり高機能ですが一般的には標準のbashが使われることが多いので、できるだけbashを使いやすくなるよう .bashrcの設定をカスタマイズしてます。

.bashrcの内容

とりあえず現状は以下のようにしてます。


# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

# User specific aliases and functions

## カスタマイズ設定
# プロンプトの設定
case ${UID} in
0)
PS1='\[\033[31m\]${PWD}\$\[\033[0m\] '
PS2='\[\033[31m\]>\[\033[0m\] '
[ -n "${REMOTEHOST}${SSH_CONNECTION}" ] && PS1='\[\033[30m\]\h'" ${PS1}"
;;
*)
PS1='\[\033[37m\]\w:\$\[\033[0m\] '
PS2='\[\033[37m\]$\[\033[0m\] '
[ -n "${REMOTEHOST}${SSH_CONNECTION}" ] && PS1='\[\033[36m\]\D{%F} \t \u@\h'" ${PS1}"
;;
esac

# ターミナルの表示設定
case "${TERM}" in
kterm*|xterm)
PROMPT_COMMAND='echo -e "\033]0;'"${USER}@${HOSTNAME%%.*}:"'${PWD}\007\c"'
;;
esac

# ヒストリ系の環境変数の設定
export HISTSIZE=100000
export HISTFILESIZE=100000
export HISTCONTROL=ignoredups
export HISTIGNORE=?:??:exit
export HISTFILE=~/.bash_history/.bash_history-$OSTYPE-`date +%Y%m%d`

# 標準エディタ環境変数の設定
EDITOR=vim

# ロケール環境変数の設定
LANG=ja_JP.UTF-8

# パスの設定
PATH=$PATH:~/bin

export PATH LANG EDITOR

# .inputrcの読み込み
[ -f ~/.inputrc ] && bind -f ~/.inputrc

.inputrcに readline の設定を記載し、読み込ませます。


$if Bash
set show-all-if-ambiguous off

set bell-style none

set visible-stats on

set completion-ignore-case on

set horizontal-scroll-mode off

set bell-style none
set expand-tilde off

set convert-meta off
set input-meta on
set output-meta on

space: magic-space

"\C-p": history-search-backward
"\C-n": history-search-forward
"\e[A": history-search-backward

"\e[B": history-search-forward

"\C-xp": "PATH=${PATH}\e\C-e\C-a\ef\C-f"

"\es":"\C-e\C-uls\C-m"

"\C-g": ""
"\C-gr": "grep -r ./\eb\C-f \"\"\C-b"
"\C-gg": "grep *\C-b\C-b \"\"\C-b"

"\e\"": "\eb\"\ef\""

"\e\"": "\eb\"\ef\""
"\e\'": "\eb\'\ef\'"
"\e\`": "\eb\`\ef\`"
"\e\]": "\eb\[\ef\]"
"\e\[": "\eb\[\ef\]"
"\e\}": "\eb\{\ef\}"
"\e\{": "\eb\{\ef\}"
"\e\)": "\eb\(\ef\)"
"\e\(": "\eb\(\ef\)"

$endif

おわりに

もっと良い設定があれば随時カスタマイズしていこうと思います。


rsyslogの基本設定とログのプライオリティ情報の出力

$
0
0

はじめに

syslogを利用して出力されるログを、 warnerrなどのプライオリティ文字列の出力の有無でZabbixでのキーワード監視をしようとしたところ、デフォルトの設定ではプライオリティの情報が出力されない(出力されるメッセージ自体にこれらの文字列が出力されることはある)ことがわかりましたので、rsyslogの基本設定とプライオリティ情報を出力させるための設定について調べたことをメモします。

rsyslog.confのフォーマット

rsyslog.confの書式は以下になります。


selector action
  • selector・・・出力するログの内容の指定
  • action・・・ログの出力先の指定
selector

selectorは出力するログの内容を指定するもので、「facility」と「priority」を.で接続したものになります。特定のactionに対して複数のselectorを指定したい場合は、;で接続します。

例えば、/var/log/messagesへ出力されるログのselectorは以下のようになっています。*.infoでinfoレベル以上のログは全て出力し、あとに続くmail.none;authpriv.none;cron.noneで、メール、認証サービス、cron関連のログは除くような指定がされています。


*.info;mail.none;authpriv.none;cron.none
facility

facilityはログの種類を示します。あらかじめ定義されているものと独自に利用できるものがあります。

facility対象のログ
auth(security)認証サービスのメッセージ(現在はauthprivが推奨されている)
authpriv認証サービス(カテゴリはauthと同じ。authとは出力結果が異なる)
croncronのメッセージ
daemonデーモンのメッセージ
kernカーネルのメッセージ
lprプリンタサービスのメッセージ
mailメールサービスのメッセージ
newsニュースサービスのメッセージ
syslogsyslogのメッセージ
userユーザープロセスのメッセージ
uucpuucp転送を行うプログラムのメッセージ
local0~7独自に利用できるファシリティ
priority

priorityはログのレベルの重要度を設定します。通常は指定したpriority以上のログが出力されます。例えば、errを指定すればcritalertemergのログも出力されます。

>
priority内容
debugデバッグ情報
info情報
notice通知
warn警告
err一般的なエラー
crit致命的なエラー
alert緊急に対処すべきエラー
emergシステムが落ちるような状態
action

actionには、selectorで指定したメッセージをどこに出力するかを設定します。

  • 指定したファイルのパスに出力する
  • |(パイプ)でほかのプログラムに渡す
  • @ホスト名で指定したホストに転送する
  • ユーザーのコンソール(/dev/condole)に出力
  • 指定したユーザに通知

テンプレートやマクロでのログ出力内容のカスタマイズ

rsyslogで出力されるログをカスタマイズするにはテンプレートという機能を使用します。$templateという記述で定義します。その際、マクロという定義を使って出力する内容を指定できます。マクロは%マクロ名%のように、前後に「%」を付けて使用します。

ファシリティ用途
msgログメッセージ
hostnameログを出力したホストの名前
fromhostログを受け取ったホストの名前
programnameプログラム名
syslogfacilityファシリティ(数字)
syslogfacility-textファシリティ(テキスト)
syslogseverityプライオリティ(数字)
syslogseverity-textプライオリティ(テキスト)
syslogprioritysyslogseverityと同等
syslogpriority-textsyslogseverity-textと同等
timegeneratedログを受け取った日時
timereportedログが出力された日時
timestamptimereportedと同等
$now現在時刻(書式:YYYY-MM-DD)
$year現在の年(4けた)
$month現在の月(2けた)
$day現在の日(2けた)
$hour現在の時(24時間表記、2けた)
$minute現在の分(2けた)

/var/log/messagesにファシリティのプライオリティの情報を出力する場合は、/etc/rsyslog.confへ以下のような指定をします。


# 既存/var/log/messagesへのログ出力設定をコメントアウト
#*.info;mail.none;authpriv.none;cron.none /var/log/messages

# 新規に設定を追加
$template mytemplate,"%timegenerated% %hostname% %programname% %syslogpriority-text% %msg%\n"
*.info;mail.none;authpriv.none;cron.none /var/log/messages;mytemplate

設定をおこなったあとは rsyslog を再起動します。


# service rsyslog restart

おわりに

以上で設定は終了です。

参考

Mac OS X YosemiteでのVagrant環境構築と基本的な使い方

$
0
0

はじめに

Vagrantとは、仮想マシンの作成や環境構築、仮想マシンの破棄までを自動化するツールです。Vagrant用の構成情報を記述した設定ファイルを用意して、vagrant用の様々なコマンドを実行するだけで仮想ディスクイメージのダウンロードや仮想マシンの作成および起動、停止、ssh接続等が実行できます。

Vagrantを利用することで、同一構成の複数の仮想マシンを簡単に作成できます。テスト用の仮想環境が必要な場合に利用されることが多いようです。 作成した仮想マシンはコマンドで簡単に破棄できるため、実運用環境をVagrantで作成することは推奨されていません。

Vagrant自体には仮想化に関する機能は搭載されていないため、別途仮想化ソフトウェアが必要です。現在公開されている最新版であるVagrant 1.7系ではVirtualBoxがデフォルトで利用可能な仮想化ソフトウェアとなっておりますが、DockerやHyper-Vもサポートされているようです。また、別途プラグインを導入することでVMwareやXen、KVM、AWSも利用可能になります。

Vagrant環境構築

Vagrantのダウンロードとインストール

公式サイトから、 Vagrantのdmgをダウンロードしてインストールします。

インストールするとインストール実行ユーザのホームディレクトリに.vagrant.dフォルダが作成されます。 これがVagrantのホームディレクトリとなっております。 Vagrantのホームディレクトリを変更するには環境変数VAGRANT_HOMEにディレクトリを設定します。

※.vagrant.d以下のディレクトリ

.vagrant.d
boxes
data
gems
insecure_private_key
rgloader
setup_version
tmp
VitualBoxのダウンロードとインストール

VirtualBoxを公式サイトからダウンロードしてインストールします。

Box(Vagrantで利用するイメージファイル)の追加

Vagrantで利用する仮想マシンイメージファイルをBoxといいます。

boxはvagrant box addコマンドによってVagrantに追加されます。このコマンドは、複数のVagrantにてboxを再利用するために、特定の名前でboxを保存します。

boxは下記の公式サイトから取得します。

以下は、CentOS 6.5のboxファイルをcentos65という名前でVagrant上に保存します。取得したファイルは~/.vagrant.d/boxes/へ保存されます。


vagrant box add centos65 https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box
==> box: Adding box 'centos65' (v0) for provider:
box: Downloading: https://github.com/2creatives/vagrant-centos/releases/download/v6.5.3/centos65-x86_64-20140116.box

vagrant box listコマンドで登録されているboxファイルの一覧を確認できます。


$ vagrant box list
centos65 (virtualbox, 0)
Vagrant環境作成

Vagrantでは、Vagrantfileというファイルに、作成する仮想マシンの設定情報を記述します。 vagrant initコマンドを実行することで、Vagrantfileが生成されます。これによってカレントディレクトリをVagrant環境にするために初期化されます。

以下にCentOS6.5のVirtualBox仮想マシン用のVagrant環境作成用ディレクトリを作成します。


$ mkdir -p ~/Work/vagrant/CentOS65
$ cd ~/Work/vagrant/CentOS65

使用するboxファイルを指定してvagrant initコマンドを実行します。これによって使用するboxファイルに合ったVagrantfileが作成されます。


$ vagrant init centos65
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
仮想マシンの起動

Vagrantfileを作成したディレクトリ内でvagrant upを実行して仮想マシンを作成して起動できます。


$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos65'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vagrant_default_1443274625036_48248
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if its present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => /Users/shimizu/WORK/vagrant
仮想マシンへのSSH接続

vagrant sshコマンドで仮想マシン環境へssh接続できます。


$ vagrant ssh
[vagrant@vagrant-centos65 ~]$
[vagrant@vagrant-centos65 ~]$ exit
logout
Connection to 127.0.0.1 closed.
仮想マシンの停止

vagrant haltコマンドで仮想マシンを停止できます。


shimizu@MacBook-Air-Mid-2011.local ~/WORK/vagrant/centos65:$ vagrant halt
==> default: Attempting graceful shutdown of VM...

おわりに

以上、Vagrantの基本的な使い方です。

Apacheでセマフォを解放

$
0
0

はじめに

Apacheが応答不能になり、再起動しても起動できなくなってしまったので確認すると、セマフォを使い切っていたことが問題だったようなので、その際に調べたことなどをメモします。

セマフォの解放

セマフォとは

セマフォはマルチタスクOSなど、並行して複数のタスク/プロセスが動作するオペレーティングシステムで用意されている仕組みで、既定数以上のプロセスが共有資源(変数やメモリ、ファイル等)に同時にアクセスしないようにカウンタを使って制御する仕組みです。
マルチタスクOSなど、並行して複数のタスク/プロセスが動作するオペレーティングシステムで用意されています。

例えば、IPC(UNIXのAPIの一種)ではプロセス間通信のための機能として用意され、プロセス間の共有資源へのアクセス衝突を防止(排他制御)するために共有メモリー上のフラグ変数を格納したデータ配列、およびそれに対する操作機能として提供/利用されています。
OSにより仕様や使い方に差はありますが、一般にセマフォ用のデータは配列のためフラグは複数個用意することが可能で、処理内容によって使い分けることができます。

原因確認

異常があった場合に確認するものの1つはログです。Apacheのログを見ると以下のエラーが出ていました。


[emerg] (28)No space left on device: Couldn't create accept lock ($APACHE_LOG_DIR/logs/accept.lock.12236) (5)
Notice: cleaning up shared memory

Apacheのログにこのようなエラーが出力されていると、OSで利用可能なセマフォが限界値に達してしまったために、新しいセマフォを使ってプロセス(ここではApache)を起動することができなくなっている可能性があります。

このような場合、以下のコマンドを実行してセマフォの情報を表示して、使用中のセマフォの数を確認します。


# ipcs -s

------ セマフォ配列 --------
キー semid 所有者 権限 nsems
0x0052e2c1 0 httpd 600 17
0x0052e2c2 32769 httpd 600 17
0x0052e2c3 65538 httpd 600 17
0x0052e2c4 98307 httpd 600 17
0x0052e2c5 131076 httpd 600 17


# ipcs -s | grep httpd | wc -l
128

それが以下カーネルパラメータの一番右の設定値と同じであれば、セマフォが原因になります。


# sysctl -a | grep kernel.sem
kernel.sem = 250 32000 32 128

カーネルパラメータは以下を意味します。

パラメータ設定例説明
kernel.semSEMMSL SEMMNS SEMOPM SEMMNIスペースで区切られた4つの値で設定します。4つの値はそれぞれ以下を意味します。

SEMMSL セマフォ数の最大値
SEMMNS システム全体のセマフォの最大値
SEMOPM semop(2)コールに指定されるオペレーション数の最大値
SEMMNI セマフォ識別子の最大値

sysctlの結果から、ここではセマフォの限界値が128個であることを意味します。この結果とipcsで出力される結果の個数が128であれば、

復旧方法

こうなった場合、不要と思われるセマフォを使っているプロセスをKILLすることで復旧できます。

プロセスIDを1つずつ削除するには以下のコマンドを実行します。


# ipcrm -m プロセスID

httpdのプロセスIDを一度に取得して削除するには以下のコマンドを実行します。


# for i in `ipcs -s | awk '/httpd/ {print $2}'`; do (ipcrm -s $i); done

おわりに

以上がApacheのセマフォを解放する手順になります。

参考

さくらのVPS 512のFreeBSDでZFSのメモリ設定

$
0
0

はじめに

さくらのVPS 512のFreeBSDでZFSを使ってますが、動作しているプロセスでメモリ使用量が高いものはないにもかかわらずメモリ使用率が高く、どうもZFSがメモリを多量に消費してswapが多発いるようでした。
その際に対応した内容を記載します。

カーネルとZFSのメモリパラメータの見直し

カーネルに割り当てるメモリと ZFS のキャッシュに割り当てるメモリの2つを調整します。

カーネルパラメータの見直し

1GBの物理メモリがある状態では、FreeBSDのカーネルに割り当てられるメモリはデフォルトでは以下でした。


> sysctl -a | grep vm.kmem_size
vm.kmem_size_scale: 1
vm.kmem_size_max: 1319413950874
vm.kmem_size_min: 0
vm.kmem_size: 1017532416

カーネルに割り当てるメモリとその最大値を物理メモリを超えない範囲で設定しておきます。いろいろ状態を見ながら、以下のように/boot/loader.confへ追記しました。


vm.kmem_size="330M"
vm.kmem_size_max="512M"
ZFSのメモリチューニング

ZFSのARCに割り当てられるメモリはデフォルトでは以下でした。


vfs.zfs.arc_min: 79494720
vfs.zfs.arc_max: 635957760

ZFS ARCに割り当てるメモリの最大値とキャッシュに割り当てるサイズを調整しておきます。いろいろ状態を見ながら、以下のように/boot/loader.confへ追記しました。


vfs.zfs.arc_max="64M"
vfs.zfs.vdev.cache.size="4M"
一般的な設定

最後にZFSの一般的な以下の設定を/boot/loader.confへ追記しました。


vfs.zfs.prefetch_disable="1"
vfs.zfs.txg.timeout="5"
kern.maxvnodes=250000
vfs.zfs.write_limit_override=1073741824

おわりに

今のところこれでだいぶ安定していますが、しばらく状態を見ながら必要に応じてパラメータをいじっていこうと思います。

参考

FreeBSD 10.1-RELEASEをFreeBSD 10.2-RELEASEへアップグレード

$
0
0

はじめに

2015/8/13 FreeBSD 10.2-RELEASEが公開されました。

さくらのVPSで使っているFreeBSD 10.1-RELEASEを10.2-RELEASEへアップグレードしてみましたので、その際に実施した手順を記載します。

FreeBSD 10.1-RELEASEを10.2-RELEASEへアップグレード

公式マニュアルの手順を元に、アップデートを実施します。

実行環境

実行環境は以下となります。

プラットフォームさくらのVPS 512
OSFreeBSD 10.1-RELEASE-p0 (amd64)
FreeBSDのアップグレード

アップグレードを実施します。まず、rootにスイッチします。


> su -
アップグレード

freebsd-updateコマンドを使ってFreeBSD10.1-RELEASEをFreeBSD 10.2-RELEASEへアップグレードします。


# freebsd-update -r 10.2-RELEASE upgrade

更新対象となるファイルに対して、Does this look reasonable (y/n)?(変更に問題ないか?)といったことを何度か聞かれるので、一応確認して問題なければy(yes)と入力します。


Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 10.1-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic src/src world/base

The following components of FreeBSD do not seem to be installed:
world/doc world/games world/lib32

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.2-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 10.1-RELEASE for merging... done.
Preparing to download files... done.
Fetching 41092 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....



40930....40940....40950....40960....40970....40980....40990....41000....41010....41020....41030....41040....41050....41060....41070....41080....41090. done.
Applying patches... done.
Fetching 4756 files... done.
Attempting to automatically merge changes in files... done.

The following changes, which occurred between FreeBSD 10.1-RELEASE and
FreeBSD 10.2-RELEASE have been merged into /etc/ntp.conf:
--- current version
+++ new version
@@ -1,7 +1,7 @@
#
-# $FreeBSD: releng/10.1/etc/ntp.conf 259974 2013-12-27 23:09:40Z delphij $
+# $FreeBSD: releng/10.2/etc/ntp.conf 285612 2015-07-15 19:21:26Z delphij $



/var/db/etcupdate/current/root/.login
/var/db/etcupdate/current/root/.profile
/var/db/etcupdate/log
/var/db/mergemaster.mtree
/var/yp/Makefile.dist
To install the downloaded upgrades, run "/usr/sbin/freebsd-update install".
カーネル/カーネルモジュール更新

更新ファイルはまだ反映されていないので、上記freebsd-updateコマンド実行後の最後のメッセージにある通りに、freebsd-update installコマンドを実行します。


# freebsd-update install

更新が反映(ディスクへ書き込み)されます。


Installing updates...
Kernel updates have been installed. Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

上記メッセージに表示されているとおり、OS再起動を実施し、新しいカーネル(10.2-RELEASE)で起動させます。


# shutdown -r now

起動後、OSバージョンが10.2-RELEASEとなっていることを確認します。


> uname -r
10.2-RELEASE
古いライブラリ/ファイル類の削除

rootへスイッチします。


> su -

再びfreebsd-updateコマンドを実行します。


# /usr/sbin/freebsd-update install

古い共有ライブラリとオブジェクトファイルを削除されます。


Installing updates...
Completing this upgrade requires removing old shared object files.
Please rebuild all installed 3rd party software (e.g., programs
installed from the ports tree) and then run "/usr/sbin/freebsd-update install"
again to finish installing updates
ZFSファイルシステムとストレージプールの更新

ファイルシステムにZFSを使用している場合、現在動作しているZFSファイルシステムとストレージプールに対して以下のコマンドを実行してアップグレードを実行します。


# zpool upgrade -a

This system supports ZFS pool feature flags.

Enabled the following features on 'rpool':
spacemap_histogram
enabled_txg
hole_birth
extensible_dataset
embedded_data
bookmarks
filesystem_limits

If you boot from pool 'rpool', don't forget to update boot code.
Assuming you use GPT partitioning and da0 is your boot disk
the following command will do it:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

メッセージの最後に表示されている通り、ディスクにbootコードを書き見ます。


# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
bootcode written to ada0
パッケージのアップデート

最新のバイナリパッケージへアップデートします。


# pkg upgrade -f

おわりに

以上で、FreeBSD 10.1-RELEASEから10.2-RELEASEへの更新が完了しました。

Viewing all 51 articles
Browse latest View live