AR ホームベーカリー

オイラのアウトプット用ホームベーカリー！

RDS でパブリックアクセスを許可する

AWS RDS

RDS を利用していて、グローバルから通信させなければ行けない事案が出てきてクッソー！となりながら、セキュリティグループと grant で指定の IP を利用できるように設定した。 が、通信できない。 （Can’t connect to MySQL server となる）

なんでかなーと考えて show grants など眺めていたけど、なんのことはなく、最初にパブリックアクセスを想定していなかったので、RDS の設定が以下のようになっていた。

  • セキュリティとネットワーク
    • パブリックアクセス可能
      • いいえ

ふんがー！ という訳で、「インスタンスの操作」→「変更」→「パブリックアクセス可能」を「はい」にして変更……できない。 VPC の DNS がどうとかいうエラーメッセージだった、んん？DNS 変更できない？ という訳で RDS が所属する VPC の設定を確認したところ、以下のようになっていた。

  • 「概要」タブ
    • DNS ホスト名
      • いいえ

ははーんこれか。 ダッシュボードから該当の VPC を選択して、「アクション」→「DNS ホスト名の編集」→「はい」とする。

即時反映されるので、RDS のダッシュボードに戻って「インスタンスの操作」→「変更」→「パブリックアクセス可能」を「はい」にして変更を行う。 この時、「メンテナンス」項目に存在する「すぐに適用」にチェックを入れておくと、変更を確定したあとすぐに RDS の状態が変更中になる。 （ちょっと時間がかかるので、運用中のサービスと接続している場合は気をつけた方がよさそう）

クソデカログファイル君をカットする

memo

特定の行から行末までを切り出す

+100 となってる所に開始行数を入れる。

tail -n +100 production.log > production_100kara.log

特定の行〜特定の行を切り出す

-e 開始行,終了行pとする。 終了行に p を付けるのがポイントらしい。

sed -n -e 101000,102000p production.log > production_kiridashi.log

KP41 病を患っていました

memo

こういうのがあるから自作 PC の内部をきっちり配線すると地獄を見る……連休中でよかった。

KP41 is 何

Kernel Power 41 とか Windows のログに出るやつです。 ググるとめっちゃ悲鳴が見える。

環境

発売日にご祝儀価格でそろえたので今の価格の1.5倍くらいした。

どうしたの？

以下の手順で解決を図りました。

最初にしたこと

UEFI からメモリに喝入れ（電圧上げ）を行った。 1.6V → 1.65V に変更。 メモリがめっちゃ消耗するけどしゃーなし！って感じで実行したところ、一週間くらいは問題出なくなった。

次にしたこと

まあ全部だめでしたね！

  • チップセットのドライバアップデート
  • GTX 750 のドライバアップデート
  • USBサウンドデバイスの取り外し
  • PT3 の取り外し
  • OS 再インストール

そもそもどのタイミングで KP41 が発生するのか

あーんこれビデオカードに負荷かかるタイミングで落ちてねえか？

ビデオカード交換する？

予備は RADEON の結構古いモデルで、ついでにダウンクロックしてあるやつだった気がするのでそれはちょっとなーって感じ。 ビデオカードに負荷がかかるタイミングで落ちる、という線から電圧が足りてねえ感じあるのでは？動物電源で鍛えられた俺たち(ry ってことで、予備の電源と交換。

交換先の電源

株式会社サイズ ｜ 商品詳細 ｜ストロンガー

どっかの書き込みで、RAM と PCI-Express は 3.3V を使う、みたいなことが書いてあったので、交換前の電源と比べて予備の電源のほうが、各出力大きいことを確認して交換開始ー。 一日かかったゾ。

交換後

今のところ負荷かけまくっても落ちないのでたぶん電源交換で正解だったようです。 ちなみに電源交換前に OS 再インストールして環境飛ばしちゃったけど、これ再インストールする必要なかったかもわからんね……。

結論

Apple 製品に Windows いれようぜ！って感じでした。なんだかんだ言って Mac てやつは製品として安定している感ある。

Macbook 上で Vagrant が扱う仮想マシンの可変サイズのストレージのサイズを小さくしたい

memo

タイトルの通りです。

ナンデ？

RHEL/CentOS の 5 とか 6 といった環境に、レガシーな Ruby や PHP の環境を複数用意する必要があり、Vagrant で管理して色々作業していると、いつの間にか Macbook 自体のディスクがたりねーな？となったのが発端です。

Vagrant が扱う、と行っても実際に仮想マシンの管理をしているのは VirtualBox となるので、どちらかというと VirtualBox の扱う仮想マシンの〜、というのが正しいかもしれませんね。

どうする

こうする。

VirtualBox の仮想ディスクサイズを小さくする | dreamin'up4u

  • ディスクを小さくしたい仮想マシンを起動する ( $ vagrant up )
  • 対象の仮想マシンにログインする ( $ vagrant ssh )
  • ログインした先で、dd コマンドで空き領域を 0 埋めして削除する ( $ dd if=/dev/zero of=zero bs=4k; \rm zero )
    • 「ディスクが一杯です」って言われてから、0 埋めしたファイルが削除されるので、標準出力のエラーに怯える必要はない
  • 対象の仮想マシンをシャットダウンする ( $ vagrant halt )
  • 対象の仮想マシンのストレージの UUID を調べる ( $ VBoxManage list hdds )
  • 対象の仮想マシンのストレージの UUID を用いて圧縮コマンドを実行する ( $ VBoxManage modifyhd [対象の UUID] compact )

現実に目を向ける

Vagrant が作成する仮想マシンのファイル形式は「vmdk」となるため、上記の手順だと「圧縮できないよ」とエラーが帰ってきます。 上記手順で圧縮できるのは、

  • 可変サイズのストレージ
  • vdi 形式

のみとなりまーす！ちくしょう！

増え続けるストレージに対応する手段は？

ない。 素直にイメージを削除するか転送速度が実用に耐えるなら、外付け HDD を用意するのが良い。 Thunderbolt 接続とかだといいんじゃろうか……。

ちなみに、vmdk -> vdi と変換してから、上記の手順で compact をしてサイズを圧縮し、再び vmdk に戻すことで解決をはかる、という手段もあるそうです。 しかしその時点で、仮想マシンのファイルサイズの二倍以上を扱えるストレージの空きが必要であり、今はもうそんな余裕がないので無理でした。 つまり死ぬしか無い。がくー。

複数の AWS アカウントを操り S3 にファイルをアップロードする

AWS のアカウントを追加する

利用するアカウントには S3 へのアクセスポリシーが設定されているものとする。

macbook:~ user$ aws configure --profile NAME
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: 
Default output format [None]:
  • NAME
    • 何かわかりやすい名前を指定する。今後コマンド利用する際に指定する名前なので少し考えよう。
  • AWS Access Key ID
    • AWS の IAM 管理から発行した値
  • AWS Secret Access Key
    • AWS の IAM 管理から発行した値
  • Default region name
    • 東京の場合は「ap-northeast-1」
  • Default output format
    • 何も指定しないと記述されないが、json になる

追加できたら、~/.aws/config に追記される。

S3 が見えるか、追加した profile を指定して確認する

macbook:~ user$ aws s3 ls --profile NAME
2017-03-15 22:28:15 muccha-good-looking-bucket

見えましたね。

ファイルをアップロードして確かめてみる

macbook:~ user$ aws s3 cp ~/Pictures/yakiniku.jpg s3://muccha-good-looking-bucket/ --profile NAME
upload: Pictures/yakiniku.jpg to s3://muccha-good-looking-bucket/yakiniku.jpg

このままだとアクセスしても Access Denied になります。 S3 のマネジメントコンソールから、yakiniku.jpg の権限を「全員」に「開く/ダウンロード」を指定して保存しましょう。

上記のバケット名や画像は実際には存在しないのですが、以下のような URL とすることでブラウザからアクセス出来ることを確認しましょう。

http://muccha-good-looking-bucket.s3-ap-northeast-1.amazonaws.com/yakiniku.jpg

見えたら成功です。

ちなみに

アップロードする時に権限を付与できるので、以下のようにすればマネジメントコンソールでの操作しなくても全世界に公開できると思います。

macbook:~ user$ aws s3 cp ~/Pictures/yakiniku.jpg s3://muccha-good-looking-bucket/ --acl public-read --profile NAME

Logwatch にめっちゃ「network unreachable resolving」が出る

Linux memo

他所から頼まれたサーバの保守するときに、まず Logwatch が何故か root ユーザのローカルメールボックスに向いてるので、保守用のアドレスに向ける事、たまにありますよね。 （本当はちゃんと運用されていて欲しい……）

続きを読む