2020年5月29日金曜日

stackdriver-agent のエラー can not take infinite value に対処する

TL;DR

stackdriver-agentcollectd

write_gcm: can not take infinite value
write_gcm: wg_typed_value_create_from_value_t_inline failed for swap/percent/value! Continuing.

とか言ってたら、以下のように編集して、

vim /etc/stackdriver/collectd.conf
-LoadPlugin swap
-<Plugin "swap">
-  ValuesPercentage true
-</Plugin>
+#LoadPlugin swap
+#<Plugin "swap">
+#  ValuesPercentage true
+#</Plugin>

stackdriver-agent を再起動しましょう。

service stackdriver-agent restart

何か起きたか

GCE 仮想マシンに Stackdriver Agent をインストールして動かし始めたら、以下なエラーが出ていた。

$ journalctl -u stackdriver-agent.service
  ...略...
May 29 05:34:55 myhost collectd[10338]: write_gcm: can not take infinite value
May 29 05:34:55 myhost collectd[10338]: write_gcm: wg_typed_value_create_from_value_t_inline failed for swap/percent/value! Continuing.
May 29 05:34:55 myhost collectd[10338]: write_gcm: can not take infinite value
May 29 05:34:55 myhost collectd[10338]: write_gcm: wg_typed_value_create_from_value_t_inline failed for swap/percent/value! Continuing.
May 29 05:34:55 myhost collectd[10338]: write_gcm: can not take infinite value
May 29 05:34:55 myhost collectd[10338]: write_gcm: wg_typed_value_create_from_value_t_inline failed for swap/percent/value! Continuing.

何が問題だったか

ログを見る限り、 OS に Swap 領域が存在しないにもかかわらず、

$ free
              total        used        free      shared  buff/cache   available
Mem:        7493724     3432032     1684776      360984     2376916     3396824
Swap:             0           0           0

Swap 領域の使用率のメトリクスを計算しようとして、ゼロ除算してるっぽい。

解決策 or 回避策

Swap 領域のモニタリングをしないようにした。

stackdriver-agent が利用する collectd の設定ファイルは以下にある。

vim /etc/stackdriver/collectd.conf

これを、以下のように編集し、

-LoadPlugin swap
-<Plugin "swap">
-  ValuesPercentage true
-</Plugin>
+#LoadPlugin swap
+#<Plugin "swap">
+#  ValuesPercentage true
+#</Plugin>

stackdriver-agent を再起動した。

service stackdriver-agent restart

出なくなった。

完。

2019年12月27日金曜日

Mac で sh/bash/zsh などシェルログイン時に Wireshark: Permission denied と出力される

Mac に Wireshark をインストールしてから、ターミナル起動時に

Wireshark: Permission denied

と出力されるようになってしまった。

別に ~/.bashrc 等の中で Wireshark を実行している形跡もない。

試しに他のシェルを起動してみると、 zsh でも sh でも発生する。

となると、 /etc/profile あたり?

  :
if [ -x /usr/libexec/path_helper ]; then
	eval `/usr/libexec/path_helper -s`
fi
  :

正解。

Permission denied/usr/libexec/path_helper -s を実行する際に出力されていることがわかった。

$ /usr/libexec/path_helper -s
Wireshark: Permission denied
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/djeeno/google-cloud-sdk/bin:/Users/djeeno/.asdf/shims:/Users/djeeno/.asdf/bin:/Users/djeeno/.asdf/installs/golang/1.13.5/go/bin:/Users/djeeno/go/bin"; export PATH;

path_helper について調べる。

path_helper ($PATHを設定するコマンド) (macOS, /etc/paths.d, /etc/paths, shell間をまたいだパス設定) - いろいろ備忘録日記

デフォルトのパス設定は、/etc/pathsファイルから読み取られる。
残りは、/etc/paths.dディレクトリの下から読み取られる。

なるほど。

/etc/paths.d を見てみる。

$ ls -l /etc/paths.d
total 8
-rw-------  1 root  wheel  43 11 21 08:19 Wireshark

いた。

このファイルのパーミッションが 600 で読み込み権限が無いため、 Permission denied が出ていた。

ので、読み込めるようにする。

$ sudo chmod 644 /etc/paths.d/Wireshark
Password:
$ ls -l /etc/paths.d
total 8
-rw-r--r--  1 root  wheel  43 11 21 08:19 Wireshark

これで Permission denied は出なくなった。


参考

2019年6月28日金曜日

kubectl コマンド実行時に対象となるクラスターを表示し、実行を保留して誤爆を防ぐ kubectl ラッパーを書いた

kubectl コマンドで破壊的オペレーションを実行する際、実行時の current-context を出力することで、ユーザーに実行対象の Kubernetes クラスターを確認させ、かつユーザーの入力があるまで実行を保留し誤爆を防いでくれるやつです。

# Run the `source` command to load this file into the current shell like follow:
#   $ source kubectl-wrapper.sh

# kubect-wrapper displays the current-context and prompts for user confirmation
# when trying to execute kubectl's subcommands that can update the cluster's state.
kubectl() { (
  # if has 1 argument || has -h --help --dry-run option || Sub-commands that are not dangerous if executed without confirmation; then
  if [ $# -le 1 ] || { echo " $* " | grep -Eq -- ' -h | --help | --dry-run '; } \
    || { echo " $* " | grep -Eq ' api-resources | api-version | cluster-info | completion | config | describe | diff | explain | get | logs | top | version | wait '; }; then
    command kubectl "$@"
    return $?
  fi
  printf "\e[01;33m%s\n%s\e[0m" "# CurrentContext: " "#   "
  command kubectl config current-context
  printf "\e[01;33m%s\e[0m" "# Press Enter key to continue... "
  read -r
  command kubectl "$@"
)}

GKE に限らずですが、複数の k8s クラスターを使い分けてると、 context を誤爆しそうで怖かった。

gcloud container clusters get-credentials --zone asia-east1-a --project MY_PROJECT MY_KUBERNETES_CLUSTER_NAME

動作確認は bash 入りの自機でしかしていないので悪しからず…。

2019年6月16日日曜日

WSL1 上で Docker をカジュアルに利用する

2019-06-18 ここから追記。

元々書いていた方法だと、 build image 時に以下の問題が有ると怒られたので、おとなしく DOCKER_HOST 環境変数を使うようにしました…。

SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have ‘-rwxr-xr-x’ permissions. It is recommended to double check and reset permissions for sensitive files and directories.

以下、その手順。

1. タスクトレイアイコンの Docker を右クリック → Settings から設定を開く

2. □ Expose daemon on tcp://localhost:2375 without TLS にチェックを入れる

3. DOCKER_HOST 環境変数を Docker for Windows に向ける

export DOCKER_HOST=tcp://localhost:2375

~/.bashrc は dotfiles リポジトリで一括管理しているので、
Mac でも Windows でも同じ ~/.bashrc を使いたい。
ので、以下のようにいい感じに追記した。

# If exist docker.exe in $PATH, set env:DOCKER_HOST.
command -v docker.exe && export DOCKER_HOST=tcp://localhost:2375

4. docker run hello-world

$ curl -LRsS https://get.docker.com/ | bash
   :
   :
$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the “hello-world” image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

負けた。


2019-06-18 ここまで追記。

以下、元の記事を残しますが、非推奨です。


「Ubuntu いくつと Docker いくつ、特定のバージョン同士だと動作する!」とか「DOCKER_HOST=tcp://localhost:2375」みたいなのに疲れた人用。

1. (インストール済みの場合) WSL 上でインストールした Docker を削除する

最終的に以下な状態になれば OK 。

$ docker
docker: command not found

お手元の環境に合わせて適切に削除してください。

apt purge docker.io
apt purge docker-ce

など。

2. Docker for Windows をインストールする

こちら

コマンドプロンプト上から docker.exe が実行できることを確認して下さい。

C:\Users\djeeno>docker.exe

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

...

実行できない場合は PATH が通ってないです。
Docker for Windows インストール後に一度も再起動していない場合は、再起動して OS 環境変数の PATH を読み直し。

3. WSL の PATH の通ったディレクトリ配下に以下のファイルを設置する。

こちら

手っ取り早く /usr/local/bin/docker にインストールしたい場合は以下を実行してください。

sudo curl -LRsS https://raw.githubusercontent.com/djeeno/windows/master/docker -o /usr/local/bin/docker
sudo chmod +x /usr/local/bin/docker

以下、ファイルの中身を転記。

#!/bin/sh

# This script executes a command with the same file name as the executable file itself,
# or a file name with ".exe" added after that.
# It's just like BusyBox.

command_name=$(basename "$0")

if command -v "${command_name}.exe" >/dev/null; then
  exec "${command_name}.exe" "$@"
else
  exec "${command_name}" "$@"
fi

ざっくり言うと、このファイルを docker という名前で実行すると、 PATH 配下にある docker.exe を実行してくれます。

おわり

$ type docker
docker is /usr/local/bin/docker

$ docker run hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

シンプル。

2019年3月21日木曜日

Docker コンテナが [!!!!!!] Failed to early mount API filesystems, freezing. と言って死ぬときの回避策

TL;DR

コンテナを init で起動すると死ぬ。

$ docker run -it ubuntu:16.04 init
[!!!!!!] Failed to early mount API filesystems, freezing.

--cap-add=SYS_ADMIN-v /sys/fs/cgroup:/sys/fs/cgroup:ro を付けたら行けた。

$ docker run -it --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro ubuntu:16.04 init
systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
Detected virtualization vm-other.
Detected architecture x86-64.

Welcome to Ubuntu 16.04.5 LTS!

 ...

何か起きたか

ansiblesystemd 辺りをセットアップする playbook を書いたため検証しようと思ったが、わざわざ仮想マシンを起こすのもめんどくさかった。
ので、コンテナの中で systemd を、ひいては init を起こした。

docker run -it ubuntu:16.04 init

すると、 [!!!!!!] Failed to early mount API filesystems, freezing. と出力して死んだ。

何が問題だったか

どうやらコンテナ起動コマンドを init にすると、諸々の権限が足りず起動に失敗するらしい。
( 詳細までは元気が足りず調べられていない )

解決策 or 回避策

docker run するときに capability SYS_ADMIN を追加した上で、/sys/fs/cgroup を読み込み専用でマウントしてやると起動できた。

docker run -it --cap-add=SYS_ADMIN -v /sys/fs/cgroup:/sys/fs/cgroup:ro ubuntu:16.04 init

備考

最初に Google 先生に聞いてみたときには、 docker run するときに --privileged オプションを付けて特権モードで起動しろなどという恐ろしい助言が出てきたが、試してみると確かに init は起こせた。

しかし、複数のコンテナを --privileged で起動すると謎の CPU の高騰に悩まされた。
( 確か。結構昔のことなので正確に覚えていない。 )

できることなら特権を与えるなんて危険なことはしたくなかったので、もうちょっと権限を絞りたいと思って色々試したところ、↑な感じで行けた。

SYS_ADMIN よりも細かく capabilities を絞ってできるかどうかは試せていない。


参考

2019年3月16日土曜日

tcpdump を時限開始して自動で停止させる

tcpdump を時間を指定して実行したいけど、 わざわざ cron を設定したくなかった。

以下例では、 2019 年 3 月 16 日 10:00 AM に tcpdump を開始し、 300 秒後に終了する。

while sleep 0.1; do
  if [ $(date +%Y%m%d%H%M) -ge 201903161000 ]; then
    sudo tcpdump -G300 -W1 -vvv -n -p -s 65535 -w "$(uname -n)_%Y%m%dT%H%M%S.pcap"
    break
  fi
done
  • tcpdump
    • -G {数字}: {数字}秒間実行する
    • -W {数字}: {数字}回ローテートする
    • -n: IPアドレスやポートをそのまま表示する
    • -p: プロミスキャスモード を有効にしない
    • -s: キャプチャするサイズを指定する ( MTUより大きくすれば OK )

2019年3月15日金曜日

バージョニングが有効化されている S3 バケットを削除したい

バージョニングが有効化されている S3 バケットを削除したいと思ったのですが、aws s3api に見当たらなかったので boto3 で簡単に書きました。

以下を delete-bucket.py などとして実行します。

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import boto3
from boto3.session import Session

boto3.set_stream_logger()

session = Session(profile_name='YOUR_AWS_PROFILE_NAME')
s3 = session.resource('s3')
bucket = s3.Bucket('YOUR_S3_BUCKET_NAME')

# 全オブジェクトの削除
bucket.object_versions.delete()

# バケットの削除
bucket.delete()

実行するときの注意

上のまま実行すると、標準出力に大量のログ(削除したオブジェクトのバージョンの一覧)が出力されるので、以下のようにして実行することをおすすめします。

$ python ./delete-bucket.py | gzip -c >./delete-bucket_$(date +%Y%m%d_%H%M%S).log.gz

参考

2019年3月13日水曜日

diff コマンドに色をつけたいけど colordiff みたいな別のコマンドはインストールしたくない

色付き diff が見たいたいけど colordiff みたいな別のコマンドはインストールしたくないシーンがあったので、 プレーンな diff コマンドに bash で、というか主に sed で、無理やり色をつけました。
ssh先 ( 最近だと kubectl exec ですかね ) のサーバーで色付き diff が欲しい時に重宝します。

difff() {(R=$(printf '\e[31m');G=$(printf '\e[32m');B=$(printf '\e[36m');W=$(printf '\e[1m');N=$(printf '\e[0m');diff -u "$@"|sed $(uname -s|grep -q '^Darwin'&&printf -- -E||printf -- -r) "s/^(@@.+@@|@@.+@@)$/$B\1$N/g;s/^(\+.*)$/$G\1$N/g;s/^(\-.*)$/$R\1$N/g;s/^[^\+\-]*((\+{3}|-{3}) [^ ].*)/$W\1/g;")}

実行例はこちら。

$ difff A.txt B.txt

git diff で見慣れた感じで出すようにしています。

Ubuntu 16.04, 同 18.04, CentOS 7, Alpine Linux (2019-03-12 時点で latest で降ってきたやつ) 辺りで動作確認済み。

-r オプションないし -E オプションがある sed + POSIX な環境であれば動くんじゃないかなと思います。

production 環境で apt install colordiff とか yum install colordiff とか apk --add colordiff なんて罪深いことはやりたくないです。

2018年7月29日日曜日

Mackerel で snap のループデバイス /dev/loop の filesystem Usage 100% を 無視する

TL;DR

mackerel-agent.conf に以下を追記

[filesystems]
ignore = "/dev/loop.*"

何か起きたか

新しいAMIからEC2を起動したらsnap でインストールされたサービスを起動すると、
空き容量には余裕があるにもかかわらず、 disk Usage 100% のアラートが発報される。

何が問題だったか

謎のデバイス /dev/loop0/dev/loop1 が増えており、かつ、それらのディスク使用率が 100% になっていた。

何ものかと調べたところ、どうやら Snappy のものらしい。

snap がデーモンを起こす際 /dev/loop[0-9]+ な命名の ループデバイスを Read Only でマウントするようで、
このデバイスの見かけ上の Usage が 100% なためdisk full アラートが発報されているようだ

解決策

mackerel-agent.conf に以下を追記。

[filesystems]
ignore = "/dev/loop.*"

これで snap がマウントするループデバイスの監視を無視することができる。

備考

なお今回の事の発端は、突然 Ubuntu 16.04 ( と Ubuntu 18.04 ) の
最新 AMI に ssm-agent がプリインストールされるようになった
こと。
この ssm-agent が snap でインストールされている。

2018年5月4日金曜日

【CentOS7】エフェメラルポートを除いた全てのアウトバウンド通信をDROP(もしくはREJECT)

「指定のポート以外の外向きの通信を禁止したい」
「Outbound通信のポートを全塞ぎしたい」
からと言って、安易に以下のように全通信をDROPしてはいけません

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 65498 -p tcp -j REJECT

エフェメラルポートまで閉じてしまうと、
内→外全ての通信が死んでしまうので…。

アウトバウンドのポートを閉じたいときは、
事前に必ずエフェメラルポートを開ける設定を入れなければいけません

加えて、エフェメラルポートを開けるルールは、
全通信をDROPするルールよりも優先度を高くしなければいけません

(ファイアウォールルールの優先度ですが、 65498 とか 65499 とか、この記事では適当な数字を使っています)


というわけで、CentOS7でエフェメラルポートを開けた後、全通信をDROPします。

エフェメラルポートを確認する

sysctl コマンドから

sysctl -a 2> /dev/null | grep net.ipv4.ip_local_port_range

proc ファイルシステムから

cat /proc/sys/net/ipv4/ip_local_port_range

以下、実行結果。

# cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

CentOS7 デフォルトのエフェメラルポートは
32768 から 60999 までのようです。

エフェメラルポートを開放する

上記で確認した ip_local_port_range を元に、許可ルールを追加します。

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 65498 -p tcp --dport 32768:60999 -j ACCEPT

全通信をDROPする

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 65499 -p tcp -j REJECT

reload して設定を反映する

firewall-cmd --reload

ついでにループバック通信を許可する

firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 65497 -p tcp -d 127.0.0.0/8 -j ACCEPT
firewall-cmd --reload