teketeke_55の日記

技術メモとか

chef-serverに接続できなくなった時の対応メモ

chef

以下のようなメッセージが出てknifeもchef-clientもうまく動作しないことがある。

 ERROR: Connection refused connecting to fedora16:4000 for /clients, retry 5/5
 Failed to authenticate. Ensure that your client key is valid

こういった場合はchef-server落ちている可能性がある。
プロセスを確認して落ちていたら起動する。

 # /etc/init.d/chef-server start
 Starting chef-server (via systemctl):                   [  OK  ]

OKは出るがプロセスが存在しない場合。

couchdbに接続できていない可能性がある。
server.rbのLOGの項目をdebug変更して再度起動スクリプトを実行

 log_level          :debug
 log_location      "/var/log/chef/debug.log"

以下のようなLOGが出力されていたらcouchdbに接続できていない。
プロセスもcouchdbが存在するか確認しておく。

 [2013-01-24T14:30:54+09:00] DEBUG: Sending HTTP Request via GET to localhost:5984/_all_dbs
 [2013-01-24T14:30:54+09:00] ERROR: Connection refused connecting to localhost:5984 for /_all_dbs, retry 1/5

念の為、chef周りもひと通り再起動。

  /etc/init.d/chef-server stop
  /etc/init.d/chef-expander stop
  /etc/init.d/chef-solr stop
  /etc/init.d/couchdb start
  /etc/init.d/chef-solr start
  /etc/init.d/chef-expander start
  /etc/init.d/chef-server start

これで正常に起動できた。
debug.logにも以下のような出力が。

 [2013-01-24T15:01:34+09:00] DEBUG: ---- HTTP Status and Header Data: ----
 [2013-01-24T15:01:34+09:00] DEBUG: HTTP 1.1 200 OK
 [2013-01-24T15:01:34+09:00] DEBUG: content-type: application/json
 [2013-01-24T15:01:34+09:00] DEBUG: date: Thu, 24 Jan 2013 06:01:34 GMT
 [2013-01-24T15:01:34+09:00] DEBUG: server: CouchDB/1.0.2 (Erlang OTP/R14B)
 [2013-01-24T15:01:34+09:00] DEBUG: content-length: 18
 [2013-01-24T15:01:34+09:00] DEBUG: cache-control: must-revalidate
 [2013-01-24T15:01:34+09:00] DEBUG: ---- End HTTP Status/Header Data ----

相変わらずchef-clientで以下のようなエラーが出る場合。

 [Thu, 24 Jan 2013 15:57:42 +0900] INFO: HTTP Request Returned 409 Conflict: Client already exists
 [Thu, 24 Jan 2013 15:57:42 +0900] INFO: HTTP Request Returned 403 Forbidden: You are not allowed to take this action.

knifeコマンドでクライアントを削除してchef-clientを実行する。

  knife client delete 【クライアント名】

またはknifeコマンドでclient 設定をやり直す

 knife counfigure -i
※設定内容適宜入力する


nginx+unicorn+gitlabの組み合わせでgitlabが起動しなくなった際の対応メモ。

gitlab

AWS　EC2　で表題構成のgitlabを運用していたのだが、EBSの初期値を使いきってしまったためDISKの拡張をした。
拡張後サーバを起動したのだがgitlabのWEBUIにアクセスできない。プロセスを見るとunicornが立ち上がっていないようだった。
手動で起動すると以下のメッセージ出力されて起動しない。

 # /etc/init.d/gitlab start
  Starting Gitlab service: master failed to start, check stderr log for details
 unicorn.

nginx側のログを見ると下記の出力が。

 2012/12/27 16:31:55 [error] 7692#0: *2 connect() to unix:/home/gitlab/gitlab/tmp/sockets/gitlab.socket failed (111: Connection refused) while connecting to upstream, client: 113.xxx.xxx.xxx, server: 54.xxx.xxx.xxx, request: "GET / HTTP/1.1", upstream: "http://unix:/home/gitlab/gitlab/tmp/sockets/gitlab.socket:/", host: "gitlab.xxx.net"

色々調べて見たがよくわからない。
　
psで再びプロセスを確認してみたところredisも起動していないことに気づいた。
起動スクリプトを叩いても起動しない。
redisのLOGを見てみると、

 [1083] 27 Dec 15:52:13 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
 [1083] 27 Dec 15:52:14 # Short read or OOM loading DB. Unrecoverable error, aborting now.

どうやらDISKを使い切った際にredisの何かが壊れたらしい。
　
redisのdumpファイルrenameしてそれぞれを起動したところうまく行った。
(vm.overcommitの設定はOOM killerが起きやすくなりそうなので設定はしなかった)

 mv /var/lib/redis/dump.rdb /var/lib/redis/dump.rdb.bk
 /etc/init.d/redis-server start
 Starting redis-server: redis-server.
 /etc/init.d/gitlab start
 Starting Gitlab service: unicorn.

参考文献:
http://rfs.jp/server/aws
https://groups.google.com/forum/?fromgroups=#!topic/redis-db/P7F3jBPu6lM
http://passingloop.tumblr.com/post/11957331420/overcommit-and-oom-killer

amazon S3 のアクセス制御をIAMポリシーで行うメモ

AWS

IAMのポリシー作成機能を使用してS3をアクセス制御する

S3だけフルアクセスできる

{
  "Statement": [
    {
     "Effect": "Allow",
     "Action": "s3:*",
     "Resource": "*"
    }
  ]
}

機能を絞る場合

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}　

S3の特定のバケットのみフルアクセス(バケットとその中身のリストは表示される)

{
  "Statement": [
    {
      "Action": [
        "s3:ListAllMyBuckets"　　#ここがないとmanagement consoleからバケット全体が見えなくなってしまう。
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::【バケット名】","arn:aws:s3:::【バケット名】/【ディレクトリ名】/*"]
    }
  ]
}

※マネジメントコンソールからはバケット自体は見えてしまう。これは仕様らしいのでFireFox Organizerなど別のツールで対応する必要がある。
https://forums.aws.amazon.com/thread.jspa?messageID=328828

S3の特定バケット特定フォルダのみフルアクセス(特定フォルダ以外は見えない)

{
 "Statement": [
   {
#マネジメントコンソールを使用しない場合やバケットの一覧を表示させたくない場合はここの "Effect"は必要ない
     "Effect": "Allow",
     "Action": "s3:ListAllMyBuckets", 
     "Resource": "arn:aws:s3:::*",
   },
   {
     "Effect": "Allow",
     "Action": [
       "s3:ListBucket",
       "s3:ListBucketVersions"
     ],
     "Resource": "arn:aws:s3:::【バケット名】",
     "Condition": {
       "StringLike": {
         "s3:prefix": "【ディレクトリ名】/*"
       }
     }
   },
   {
     "Effect": "Allow",
     "Action": "s3:*",
     "Resource": "arn:aws:s3:::【バケット名】/【ディレクトリ名】/*",
   }
 ]
}

IPアドレス制御

{　
  "Statement": [
    {
     "Effect": "Allow",
     "Action": "s3:*",
     "Resource": "*",
     "Condition": {
         "IpAddress":  {
             "aws:SourceIp": [”【接続元IPアドレス】”]
           }
        }
     }
   ]
}

httpsのみアクセスできるようにする

{
 "Statement": [
  {
    "Effect": "Deny",
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::【バケット名】/【ディレクトリ名】/*",
    "Condition": {
       "Bool":  {
           "aws:SecureTransport": "false"
      }
    }
  }
 ]
}

組み合わせ

"Statement": [
 {
   "Effect": "Allow",　
   "Action": [
     "s3:ListBucket",
     "s3:ListBucketVersions"
   ],
   "Resource": "arn:aws:s3:::【バケット名】",　※取得するバケットを制限
   "Condition": {
     "StringLike": {
       "s3:prefix": "【ディレクトリ名】/*”
     }
   }
 },
 {
   "Effect": "Allow", #接続元IPアドレスによる制御
   "Action": "s3:*",
   "Resource": "arn:aws:s3:::【バケット名】/【ディレクトリ名】/*",
   "Condition": {
     "IpAddress":  {
            "aws:SourceIp": ["【接続元IP1】","【接続元IP2】"]
   }
 },
  {
    "Effect": "Deny",　#https通信のみ許可
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::【バケット名】/【ディレクトリ名】/*",
    "Condition": {
       "Bool":  {
           "aws:SecureTransport": "false"
      }
    }
  },
    {
    "Effect": "Deny",　#ACL周りの操作と、バケットの作成、削除はさせない
    "Action": ["s3:*Acl","s3:CreateBucket","s3:DeleteBucket"],
    "Resource": "arn:aws:s3:::【バケット名】/【ディレクトリ名】/*",
  }
 ]
}

参考文献：
http://docs.amazonwebservices.com/AmazonS3/latest/dev/UsingIAMPolicies.html
http://docs.amazonwebservices.com/AmazonS3/latest/dev/AccessPolicyLanguage_UseCases_s3_a.html
http://www.techtricky.com/amazon-s3-how-to-restrict-user-access-to-specific-folder-or-bucket/

CUIリモートログイン時の出力を日本語対応にする【FreeNAS】

freenas

FreeNAS(FreeBSD)の初期設定ではリモートログイン時でも日本語が文字化けしてしまう。

 # ll /mnt/vol01/public/
 total 1084
 drwxrwxrwx  57 root           wheel      80 Oct 27 10:49 ???????????????????????????/
 -rwxrwxrwx   1 root           wheel     298 Apr 11  2012 ???????????????????????????.xls*
 drwxrwxrwx  37 root           wheel      55 Nov 13 13:41 IRClog/

GUI上から操作する場合はそれほど問題ないがsshログイン時などにファイル名が判別出来ず不便なので日本語表示に対応させたい。
WEBを検索すると
http://server-setting.info/freebsd/freebsd_japanease.html
で対応する方法がわかりやすく紹介されているので試してみた。

紹介されているログイン設定ファイルを編集では下記のエラーが出てうまく行かなかったので各シェルの設定ファイルを編集する方法を実施した。

 Nov 13 14:48:01 freenas02 sshd[18875]: login_getclass: unknown class 'japanese'

  • 実行環境：FreeNAS-8.3.0-RELEASE-x64 (r12701M)
rootユーザーの場合は事前にマウントポイントを読み書き可能にしておく
 # mount -uw /
 # mount  ※read-onlyが外れているか確認

 # vi .cshrc
  #以下を追記
 setenv  LC_CTYPE ja_JP.UTF-8
 setenv  LANG     ja_JP.UTF-8

※一般ユーザーの場合は各ホームディレクトリに権限をつけて配布する。
ログインしなおして日本語が表示されているか確認する。

 # ll /mnt/vol01/public/
 total 1084
 drwxrwxrwx  57 root           wheel      80 Oct 27 10:49 初期インストールソフトウェア/
 -rwxrwxrwx   1 root           wheel     298 Apr 11  2012 バックアップ一覧.xls*


うまく見えていたらマウントポイントを読み込み専用に戻しておく

 # mount -ur /

※もしくは再起動
サーバにモニタをつないでコンソール接続してログイン場合は文字化けするので注意。
そのあたりについても先程のリンク先で紹介されている。

nagiosめも(check_log3)

nagios

webサーバのアクセスLOGから出力される

" 408

(ダブルクオートスペース408スペース)
を検知したい。

※この記事は事前にngiosサーバ、nrpeのインストールと設定が完了していることが前提。


nagiosexchangeで検索すると最近更新されたchek_log3というpluginがあったのでこれを使ってみる。
check_log2と比べると検知文字の検出回数指定やnegapatternのファイル読み込みなどができてなかなか高機能ぽい。

http://exchange.nagios.org/directory/Plugins/Log-Files/check_log3-2Epl/details

検知には監視対象機器のnrpe実行ユーザーで以下の権限が必要なので事前に準備しておく。

  • 監視対象のLOGファイルの読み取りできること
  • seekfileが存在しての読み書きできること

当初はnrpe.cfgに下記のように設定して実行してみたが正規表現とスペースがうまく処理できないようでうまく行かない。

command[check_log3]=/usr/local/nagios/libexec/check_log3.pl -l $ARG1$ -s  $ARG2$ -c  $ARG3$  -p $ARG4$

./check_nrpe -H localhost -c check_log3 -a /usr/local/nagios/etc/test.log  /usr/local/nagios/etc/seek.file.test  3 "\"\ 408\ "
CHECK_NRPE: Received 0 bytes from daemon.  Check the remote server logs for error messages.

いろいろ弄った結果、以下の設定でうまく行った。

  • nrpe.cfg(対象機器)
  command[check_log3]=/usr/local/nagios/libexec/check_log3.pl $ARG1$ -c 3 -p "\"\ 408\ "

　

  • service.cfg(監視サーバ)
  check_command                   check_nrpe!check_log3!"-l /var/log/httpd/access.log -s /usr/local/nagios/etc/seek.file"

　
ARGを一つ一つ設定した場合に手動実行ではうまく行くのだがnagiosから実行するとなぜかうまく展開されなかったり、引数の順番を変えるとエラーがでたり内部処理はよくわからないままだが、上記のようにARGを一つにすると引き渡せた。
　(nagiosからnrpeに渡される引数は""で囲まれて渡される？)
　
この設定だと対象機器側で更新が必要なので面倒だ。
nagiosサーバ側だけで完結する方法は無いものか。。。

Active Directoryユーザーログインとhomeディレクトリ作成とuserquotaを連携

freenas

※Active DirectoryとCIFSの初期設定が完了していることが前提

CIFS共有領域にユーザーがアクセスした時にアクセスしたユーザー名でディレクトリを作成しつつ
ZFSのuserquota機能でユーザーごとの容量制限を行う。
※ZFSのuserquotaはZFS バージョン5、zpool バージョン15からサポートされているようだ。

CIFSの準備

「Services」→「CIFS」のスパナアイコンをクリックして設定をする

「Homes auxiliary parameters」に以下の文言を追加する。

root preexec = /mnt/vol01/mkdir.sh %D %U

上記はCIFS共有領域にユーザーがアクセスした時に実行される。
スクリプトは実行権限を付けてFreeNASサーバの任意の場所置いておく。

mkdir.shの中身

 #!/bin/bash

 if [ ! -d /mnt/vol01/personal/$1/$2 ]; then
        mkdir /mnt/vol01/personal/$1/$2
        chmod g+s /mnt/vol01/personal/$1/$2
        chown $2:"domain users" /mnt/vol01/personal/$1/$2
        chmod 750 /mnt/vol01/personal/$1/$2
        zfs set userquota@$2=1g vol01/personal # zfs コマンドでuserquotaを設定
 fi
 exit 0

確認

windowsマシンから共有領域にアクセスすると上記で設定したディレクトリが見えているはず。
サーバにログインしてquota状況も見てみる。

 # zfs userspace vol01/personal
 TYPE        NAME       USED  QUOTA
 POSIX User  root      4.50K   none
 POSIX User  user1      34K     1G

うまく動いていれば先ほどログインしたユーザー名でquotaが設定される。

  • 参考文献

http://damedame.monyo.com/?date=20110220
http://ppona.com/gpl/iodata/usl-5p/USLSRC100/daemon/samba/040924/samba-2.2.11-ja-1.0/docs/ja/htmldocs/using_samba/ch06_06.html
http://docs.oracle.com/cd/E24845_01/html/819-6260/gazvb.html#scrolltoc

freenasでルートパーティションを読み書き可能にする

freenas
  • freenasバージョン

FreeNAS-8.3.0-BETA3-x64 (r12317M)

pkg_addやportsでパッケージを追加したかったのだが
freenasのルートパーティションは初期設定でリードオンリーに設定されているため、
ファイルやディレクトリ作成できずインストールできなかった。

 # cat /etc/fstab
 /dev/ufs/FreeNASs2a / ufs ro 1 1

 # mount
 /dev/ufs/FreeNASs1a on / (ufs, local, read-only, soft-updates)

コマンドラインから上記を編集してもシステム起動時に別のファイルを読み込んでファイルを再作成するの再起動すると元に戻ってしまう。
設定を永続的に反映するには以下にあるファイルを修正する。

  /conf/base/etc

まずはルートパーティションを書き込み可能にする。

 # mount -wu /

起動時に読み込まれるファイルを修正する。 

# vi /conf/base/etc/fstab 
 /dev/ufs/FreeNASs2a / ufs rw 1 1 # roをrwへ変更


再起動する。

 # reboot


確認

 # cat /etc/fstab
 /dev/ufs/FreeNASs2a / ufs rw 1 1
 
 # mount
 /dev/ufs/FreeNASs2a on / (ufs, local, soft-updates)
  • 参考文献

http://forums.freenas.org/showthread.php?5468-read-only-usb-filesystem&highlight=fstab